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Commonality of 
Real-Time Command 
and Control 


by George A. Gaxiola 


Figure 1. The Space Shuttle Columbia returns November 14 to Edwards Air Force Base from its historic second space mission. 


The United States defense forces over 
the past 20 years have increasingly re- 
lied on space satellite systems to sup- 
port the command and control func- 
tions for worldwide communications, 
navigation and location, weather data 
gathering and handling, and surveil- 
lance and warning missions. 

IBM’s Federal Systems Division (FSD) 
has been assisting in the development 
of the growing numbers of ground sys- 
tems to support these space missions, 


ifs 


including launching and monitoring of 
satellites. In the future, FSD will be sup- 
porting DoD Space Shuttle (Figure 1) 
and its payload operations. 

The amount of data processing re- 
quired to support the mission objec- 
tives, keep the satellites healthy, and 
provide mission data to military units 
has increased dramatically in those 
twenty years. During crises and con- 
flicts, such as Vietnam, involving 
worldwide defenses, data processing 


has improved the acquisition of data 
from satellites, the interpretation of 
satellite observed events and the sum- 
mary presentation and distribution of 
events to military forces. 


General Future Requirements 


Space makes an ideal platform for 
observing what is happening on and 
near the earth’s surface, from detection 
of nuclear explosions to the report of a 
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ing of spaceborne Observations was 
done on the ground in a batch process- 
Ing System; hours were required to pro- 
cess and analyze a few scans of data 
before reporting to the military com- 
mands. Currently some of the process- 
Ing 1s done in real time on systems with 
reports to the military commands with- 
In minutes of the event’s occurrence. 
Numerous systems are using interactive 
non-real-time processing. 

In the future, the increase in mission 
capability provided by the more sophis- 
ticated satellite missions and the in- 
creased launch size of satellites will pro- 
vide more information for the assess- 
ment and direction of the global and 
local military situation. New data pro- 
cessing techniques must be developed 
to interpret the data, fuse the data 
streams and summarize the informa- 
tion content for the user. The informa- 
tion is needed much faster today for the 
direction of crises and conflict §re- 
sponses to provide adequate time to 
assimilate the data and review alternate 
courses of action. Increases of perfor- 
mance in the real-time data processing 
systems are key to the planned imple- 
mentation of this approach. Significant 
amounts of similarity exists between 
these programs giving rise to the poten- 
tial of using common hardware and 
software across multiple projects. 


The Near Term 


During the 1980s and beyond, the 
United States space program will have 
a number of mission control centers be- 
ing upgraded or built under the aus- 
pices of DoD and the National 
Aeronautics and Space Administration 
(NASA). 
Those under DoD will include: 

e The Air Force’s Satellite Control 
Facility (SCF)—currently being up- 
graded by the IBM Federal Systems 
Division (FSD) under the Data System 
Modernization (DSM) project. 

e The Master Control Station for the 
Global Positioning System (GPS)— 
currently under development by FSD 

e The Shuttle Operations and Planning 
Complex (SOPC)—being studied by 
FSD as the mission control center for 
military shuttle missions 


° The Space Defense Operations 
Center (SPADOC),—providing cen- 
tralized command and communica- 
tions for defense purposes. 

° The Consolidated Space Operations 
Center (CSOC)—scheduled to provide 
a centralized facility for military 
space operations. 

Mission control centers under NASA 
are located at: 

e The Lyndon B. Johnson Spacecraft 
Center (JSC) 

e The John F. Kennedy Spacecraft 
Center (KSC) 

e The Goddard Space Flight Center 
(GSFC) 

In the past, centers have been devel- 
oped essentially independently, not 
drawing upon each other’s experience 
and products. Such action has resulted 
in some amount of risk, schedule and 
cost exposures that perhaps could have 
been avoided. However, recent studies 
within FSD have shown that it is highly 
desirable to develop these control 
centers so as to take advantage of com- 
mon elements in both hardware and 
software from one center to another. In 
addition, it is desirable to use existing, 
field-proven components when possi- 
ble. This commonality provides signifi- 
cant advantages in reducing develop- 
ment and life-cycle costs, improving 
schedules, and perhaps, most impor- 
tantly, enhancing reliability and thus 
reducing the overall technical risk in 
developing highly complex real-time 
command and control systems. 

Preliminary work on the feasibility 
of a commonality approach was done 
by FSD at its facility in Houston as part 
of an effort to use software from the 
Shuttle Ground-Based Space System 
(GBSS) in the Shuttle Payload Opera- 
tions Control Center (POCC), each using 
an IBM System/370 Model 168. These 
efforts were advanced in Gaithersburg 
during the proposal phases for both the 
Global Positioning System, a space- 
based RF navigation and positioning 
system, and the Data System Moder- 
nization program, an upgrade for the 
SCF. Results of these efforts showed 
that IBM’s 3030 and 4300 series pro- 
cessors provide solutions to hardware 
requirements, while significant 
amounts of existing software produced 
by other IBM divisions and FSD offer a 
large common software foundation for 
real-time command and control system 
applications. 


The common software concept rs 
in Fi 4. The nucleus of the 

shown in Figure <. 
a ‘as the software (over 
jagram contains ; iw -_ 
five million source lines) which 1s CO 
mon to GBSS, DSM, and the GPS Master 
Control Station. This includes existing 
IBM products: the Multiple Virtual 
Storage (MVS) operating system, the 
Time Sharing Option (TSO), the System 
Productivity Facility (SPF) and the Vir- 
tual Telecommunications Access 
Method (VTAM). Also included in this 
common nucleus is existing software 
developed by FSD for the Shuttle 
Ground Based System: the Program 
Management Facility (PMF), a library 
management system used to control 
software during its development; and 
the Advanced Statistics Collector (ASC), 
a performance measurement tool used 
to fine-tune the real-time system. 

Extending this nucleus of common 
software is the real-time executive 
(RTX), another GBSS-based product 
which adds to the standard MVS 
Operating system those features re- 
quired for a real-time processing envi- 
ronment. Still another layer of com- 
monality is represented by FSD software 
capabilities in display management, 
data base management and test driver/ 
scenario generation. The final layer of 
software commonality is represented by 
kernels of software in the applications 
which are typical of space-oriented 
real-time command and control sys- 
tems—telemetry, trajectory, command 
and control. 

The feasibility of a commonality ap- 
proach to real-time command and con- 
trol systems software was demonstrated 
in three related activities which used the 
Ground Based Shuttle System as a 
base. In February 1980, the GBSS pro- 
grams, (Over 1,600,000 source lines) 
were transported from NASA’s mission 
control center in Houston (where they 
were developed by FSD and executed on 
IBM 370/168 processors) to the IBM 
facility at Gaithersburg, Maryland. 
Only minor modifications to the dis- 
play hardware interfaces were required 
in order to successfully execute these 
large, complex, real-time programs in 
both IBM 3033 and 4341 processors 
under a standard Mvs Operating sys- 
tem, thereby demonstrating the upward 
and downward compatibility of the 
system. These programs were used in 
Gaithersburg as a base for the GPS 
benchmark in March 1980; for the 


ward compatibility demonstra- 
Ae in April 1980; and for the DSM 
Stage | demonstration, In November 
1980. All of these efforts were highly 

ul. 
i of this work, both GPS 
and DSM will be using all software 
elements of the common nucleus, plus 
an enhanced version of the real-time 
executive and new display software. 
Enroute to this achievement, major dif- 
ficulties were overcome, including the 
establishment of a common program- 
ming language and a common set of 
programming standards for both the 










Figure 2. Common software concept 


DSM and GPS projects. 

Further development of this concept 
is being pursued by a common systems 
development group established by FSD 
in Gaithersburg. An in-house effort, 
the group’s primary objective is to 
develop system-level software which 
can be used across multiple present and 
future command and control projects. 

Studies convincingly show that the 
commonality approach makes both 
sound technical and business sense. 
Preliminary analysis of the potential 
for commonality in application soft- 
ware such as telemetry, trajectory, and 






APPLICATION KERNELS 
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¢ Trajectory 
¢ Command 
Control 
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e Realtime Executive 
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command and control has shown the 
possibility of establishing common a 
plication software kernels which aa 
be used across projects. Thus the 
potential exists for carrying this Sik. 
monality approach beyond the system. 
level software into application pro- 
grams. One example would be the orbit 
and trajectory software required by the 
various systems. 

The commonality approach is a con- 
cept that has matured within FSD and js 
currently in practice, reducing cost and 
technical risk and improving software 
scheduling. 




























SOPC: DoD’s Control Center 
for Space Shuttle 


by Merritt E. Jones 


The United States Air Force space 
program in the mid-1980s and beyond 
will utilize NASA’s Space Shuttle Vehi- 
cle. The current AF facility, the Satellite 
Test Center (STC) at Sunnyvale, 
California, is for control and monitor- 
ing of unmanned vehicles and satellites 
and will continue in that role. The stc 
has previously utilized unmanned, ex- 
pendable launch vehicles to conduct 
space operations. The advent of the 
manned, reusable Space Shuttle launch 
vehicle for AF use requires a new DoD 
capability to function in a secure, con- 
trolled environment. This capability to 
plan and launch DoD missions will in- 
itially be provided at NASA’s Johnson 
Space Center (JSC) in an environment 
known as Controlled Mode. 


Controlled Mode 


Controlled Mode is the term used to 
describe the changes required at JSC to 
provide the secure operational environ- 
ment necessary to support DoD mis- 
sions. These changes involve hardware, 
software, facilities, procedures and per- 
sonnel. Modifications have been in 
progress since 1980 and JSC will be 
ready to support a DoD flight by 
mid-1983. 

In 1979, the Office of Management 
and Budget Alternatives Study con- 
cluded that while Controlled Mode was 
satisfactory for early DoD flight opera- 
tions, the stringent requirements based 
on Revision 8 of the DoD mission model 
could not be permanently accommo- 
dated by Controlled Mode. In addi- 
tion, a permanent JSC solution pre- 
cluded DoD mission authority, limited 
DoD mission flexibility, did not enhance 
system survivability, and did not pro- 
vide the necessary levels of security. A 
separate DoD operated facility, to be 
known as the Shuttle Operations and 


Planning Complex (SOPC), represented 
a distinctly better option. 

The study considered co-locating or 
integrating SOPC with Vandenberg Air 
Force Base, JSC, STC or the proposed 
Satellite Operations Complex (SOC). 
Co-location means that the physical 
facilities are shared but data systems 
are not. Integration includes the shar- 
ing of the data systems as well as the 
physical plant and associated services. 
The study further concluded that the 
co-location of SOPC with SOC appeared 
to be economically and operationally 
advantageous. 

SOC is the proposed backup and load 
sharing facility for STC and is an option 
to the STC upgrade, Data Systems 
Modernization, which is currently be- 
ing performed by IBM. (See article on 
page 43.) The current plans are that 
SOC and SOPC will be co-located at a 
Colorado Springs facility designated 
the Consolidated Space Operations 
Center (CSOC). The Initial Operational 
Capability date for CSOC and SOPC is 
mid-1987. 


Shuttle Operations and Planning 
Complex (SOPC) Functions 


SOPC is planned to be an upward com- 
patible version of the Shuttle planning, 
readiness and operations facilities at 
jsc. ‘‘Upward compatible”’ refers to a 
concept whereby the software is trans- 
ferred from JSC but the hardware is 
upgraded to modern technology when- 
ever possible. In other words, SOPC will 
be a functional equivalent but not a 
duplication of specified parts of JSC. 
Software impact, data security and op- 
erational concepts will be significant 
factors in determining the degree of 
duplication. 

In support of NASA Shuttle opera- 


tions, JSC performs 21 flight operations 
functions. For DoD Shuttle operations, 
a designated subset of those functions 
will be performed by SOPC and the re- 
maining ones will be provided by other 
DoD capabilities such as SOC. 

Figure 1 shows the distribution of the 
flight operations functions between 
sopc and the other DoD facilities. The 
eleven functions performed by SOPC 
are Shuttle related. The remaining 10 
functions are concerned with payloads, 
upper stages, flight feasibility analysis 
and utilization planning. The flight 
operations functions are performed in 
four consecutive time phases (Figure 2). 
The long range planning phase defines 
the users’ cargo requirements and the 
required support. This phase begins 
two to four years prior to launch and 
ends at launch minus 18 months with 
the Cargo Integration Review. The 
detailed planning phase follows and is 
directed towards preparing a flight 
ready crew and ground support team 
and flight specific data, data loads and 
documentation. It terminates at launch 
minus two days. The flight operations 
phase picks up at launch countdown 
and continues throughout the mission 
until the crew exits the Shuttle after 
landing rollout. This real-time phase 
lasts up to 30 days. The post flight 
analysis phase is the final phase. It 
begins after the real-time flight opera- 
tions are terminated and continues until 
all anomalies are resolved and data 
have been provided to the users and 
operators of the Shuttle. 

Figure 1 further indicates that the 
SOPC flight operations functions are 
provided by three major elements: 
Flight Planning Element (FPE), Flight 
Readiness Element (FRE) and Flight 
Control Element (FCE). Figure 3 depicts 
the major data systems which comprise 
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Figure 1, Allocation of Shuttle Flight Operations Functions 
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Figure 2. Flight operations time phases 





these elements. These three elements 
provide DoD the capability to monitor 
and control Shuttle missions. The SOPC 
elements and IBM’s role in their counter- 
parts at JSC are discussed below. 


Flight Planning Element 


The SOPC FPE (Figure 4) provides the 
hardware and software products to 
support DoD Shuttle mission flight de- 
sign activities and flight crew activity 
planning. 


Flight Planning Element/ 
Flight Design System 


The flight design portion of FPE is 
comprised of a conceptual planning 
system (System X) and a detailed plan- 
ning system (System Y). System x is an 
interactive minicomputer based system 
that provides the models and event pro- 
cessors necessary for a flight planner to 
determine preliminary flight profiles 
based upon a set of mission objectives 
and constraints. The flight planner then 
uses these preliminary flight profiles as 
input to System Y which utilizes high 
fidelity models to generate precision 
flight data. These two systems are col- 
lectively known as the Flight Design 
System (FDS). 

System X includes an application ex- 
ecutive developed for NASA by IBM. In 
addition to the normal initialization, in- 
terface and control functions, it pro- 
vides a user interface for an electronic 
transfer between System X and System 
Y. When DoD is operating in the Con- 
trolled Mode at JSC, this interface will 
be disabled for security reasons and a 
hand-carried tape will be used. At 
SOPC, where a secure physical con- 
figuration is available, the electronic in- 
terface and the executive will allow the 
flight planner to transfer the prelimi- 
nary data from System X to System Y 
and initiate the System Y process. The 
data can then be returned from System 
Y to System xX for input to an 
automated documentation system. 


Flight Planning Element/Crew 
Activity Planning System 


The Crew Activity Planning System 
(CAPS) supports the analysis and 
development of crew procedures and 
crew activity timelines during DoD flight 
operations. CAPS is a minicomputer 
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Figure 3. SOPC data systems A 


based system that performs timeline 
analysis, generates crew activity time- 
lines, crew reference material and flight 
procedures checklists. It can also sup- 
port near realtime mission replanning 
and contingency operations. The sys- 
tem (Level A) requirements for CAPS 
were written by IBM. 


Flight Planning Process 


The flight planning process begins 
when the Shuttle program office deliv- 
ers a set of flight requirements and con- 
straints to the flight design personnel. 

The cargo and the objectives for the 
flight have already been established. 
From this starting point, the flight 
planners develop a Conceptual Flight 
Plan (CFP). It is a preliminary attempt 
to produce a flight design that deter- 
mines the feasibility of the flight and 
technically satisfies the integrated con- 
straints. The CFP is the basic instrument 
for iteration and is developed using the 
System X portion of the Flight Design 
System. This utilization of the FDS is 
mainly an interactive use of low fidelity 
simulations. The initial CFP may be 
generated as much as five years before 
the liftoff for that flight. 

After the CFP has been reviewed and 
refined by the iteration process, work 
commences on the generation of the 
Operational Flight Plan (OFP). This 
may occur as much as a year before the 
flight and may also go through some 


DISPLAY AND 
CONTROL.SYSTEM 


Crew Training (DCS) 





degree of iteration. Approximately five 
months before the flight, the flight 
design is ‘‘frozen’’ and the final Opera- 
tional Flight Plan is published. This 
plan is used for flight simulations and 
for the System Y portion of the Flight 
Design System which is mainly a batch 
interface using sets of high fidelity 
simulations. Products generated at this 
time (e.g., trajectory tapes) are input to 
the Flight Readiness Element for use in 
onboard software and the simulator, to 
Flight Control for ground software 
testing and to the crew planning per- 
sonnel for the development of the Crew 
Activity Plan. 


Flight Readiness Element (FRE) 


This element consists of two major 
components: the Data Load Prepara- 
tion System (DLPS) and the Fixed Base 
Crew Station Simulator (FBCSS). The 
FRE provides DoD with the capability to 
support flight data file preparation, on- 
board digital data load preparation, 
flight crew training, flight operations 
Support personnel training and _in- 
tegrated rehearsals. 


Flight Readiness Element/ 
Data Load Preparation 
System 


The DLPs is the SOPC version of the 
Software Production Facility (SPF) at 
Johnson Space Center which is an 


upgrade to the Software Development 
Laboratory (SDL). It is used for 
development and reconfiguration of 
flight software to support specific 
vehicles, payloads and flight profiles. 
The SDL executes on IBM System/360 
Model 75s. IBM programs the SDL and 
will provide the software for the SPF. 
The SPF procurement for the replace- 
ment of the 360/75Ss was recently 
awarded to IBM. The new machine will 
be an IBM 3033. The data load prep- 
aration system components will be in- 
itially installed at JSC as part of the SpF 
and moved to SOPC at a later date. 
Figure 5 depicts a multi-flight com- 
puter configuration similar to that an- 
ticipated for the DLPS. The general pur- 
pose computers are laboratory versions 
of the computers onboard the Shuttle 
and are built by IBM. The Flight Equip- 
ment Interface Device (FEID) is a special 
piece of equipment also built by IBM. It 
provides the proper interface between 
the general purpose computers and a 
host computer which can simulate the 
Shuttle environment and avionic SYS- 
tems. Two other components of the 
DLPS are the mass memory unit and the 
multifunction cathode-ray tube display 
System (MCDS), provided by IBM. The 
mass Memory unit is a magnetic tape 
device which contains the data loads 
for the Shuttle onboard digital data 
systems. The DLPS produces the tape 
which is used to load the mass memory 
unit. Included in the data loads are 
software elements for the primary 
avionics system, backup flight system, 
display electronics unit, system loader 
and self-test, display text and graphics, 
Space Shuttle main engine controller, 
test control sequences, payload data in- 
terleaver and telemetry format loads. 
The primary avionics system software 
developed by IBM accounts for about 
two-thirds of the onboard software 
elements. The MCDS is the interactive 
display system utilized by the astro- 
nauts to communicate with the on- 
board computers and control the Shut- 
tle during simulations and actual mis- 
sions. The DLPS MCDS is a replica of the 
one on the Shuttle. 


Flight Readiness Element/Fixed 
Base Crew Station Simulator 


The Fixed Base Crew Station Simulator 
will provide DoD with the capability to 
plan, conduct and evaluate flight spe- 


cific training for DoD flight crews and 
payload specialists. Initially, flight crew 
training will be conducted at Jsc while 
payload specialists will train at SOPC in 
an on-orbit mission simulator. Eventu- 
ally, the simulator will allow DoD to 
conduct flight specific training of the 
flight crews at SOPC while generic flight 
training continues to be provided at 
JISC. 


Figure 6 depicts the current JSC 


FBCSS of which the sopc simulator will | 


be an equivalent. The configuration in- 
cludes a Simulation Interface Device 
(SID) and five flight computers built by 
IBM. The SID interfaces the flight com- 
puters with the simulation system and 
performs a portion of the avionics SYS- 
tem modeling. 

The simulator includes a mock-up of 
the Shuttle orbiter flight deck which 
provides the flight crews with a realistic 
training environment for all mission 
phases from prelaunch through rollout. 
Stations are provided for the com- 
mander, pilot, mission specialist and 
payload specialist. 

All simulations are in real-time with 
the capability for background jobs 
(assemblies, compilations, delogging, 
prints, etc.) during simultation. Color 
visual scenes are created for the six for- 
ward windows, the two aft windows 
and the payload bay closed circuit tele- 
vision Cathode Ray Tubes. Aural simu- 
lations include the Shuttle mechanisms 
and inflight sounds as well as com- 
munication loops. The simulator con- 
tains a Network Simulation System for 
modeling telemetry, command and the 
communications and tracking network. 
The Network Simulation System also 
provides the interface to the FCE for in- 
tegrated flight controller training. 

There are instructor and operator 
consoles that have been designed to 
provide the capability to monitor simu- 
lations in progress and to control simu- 
lation activities. An interactive display 
system provides digital and graphic 
displays and allows faults and pertur- 
bations to be entered. Monitoring and 
controls are designed such that one in- 
dividual can run a simulation or the full 
complement of instructors, operators, 
crew, and ground controllers can be 
used. 


Flight Control Element 


The FCE provides the hardware and 
software necessary to perform flight 


operations planning, Shuttle prelaunch 
Operations support, Shuttle flight 
Operation support and Shuttle opera- 
tions post-flight analysis. The FCE con- 
sists of three major systems; the Com- 
munications Interface System (CIS), the 
Data Computation Complex (DCC) and 
the Display and Control System (DCS). 
Figure 7 depicts these components at a 
high functional level. The FCE is refer- 
red to as the Shuttle Mission Control 
Center (SMCC). 


Flight Control Element/ 
Communications Interface 
System 


This system provides the interface be- 
tween SOPC and the DoD network. It 
also performs preprocessing, recording 
and distribution of telemetry, tracking, 
command, video, voice and miscellane- 
ous data within the SMCC and external 
sources. It is highly reconfigurable (as 
is the SMCC in general) and provides 
flexible data paths for the same data 
type or unique data paths for specific 
data. 

For example, the high speed launch 
and landing C-band tracking data from 
Kennedy Space Center (KSC) is routed 
through a very short path in the CIS via 
a Launch/Landing Interface Unit and 
handled by special software in the DCC. 
S-band and low speed tracking data of 
all types is processed through a slightly 
longer routing function but is passed to 
the DCC without preprocessing whereas 
the telemetry data goes through data 
quality, routing and decommutation 
functions before being sent to the DCC. 

The communications segment for 
SOPC has many functions in common 
with its counterpart in SOC. It is very 
likely that these functions will be pro- 
vided to SOPC and SOC via a common 
CSOC communications segment. The 
exact functions and equipment to be 
shared will be determined at a later 
date. 


Flight Control Element/Data 
Computation Complex 


The DCC provides the major computa- 
tional capability for the Flight Control 
Element (FCE). It also provides switch- 
ing and peripheral capability and is 
composed of three major components: 
the Shuttle Data Processors (SDPs), the 
Multi-bus Interface (MBI) and the Con- 
figuration and Switching Equipment 
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Figure 4. Flight planning element 
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(CSE). Figure 8 gives an overview of the 
major data flows and paths between 
the pcc and other SOPC and DoD com- 
ponents. ; : se 
The pcc has a switching capability 
that provides multiple high speed paths 
between the components of the CIS and 
the SDPs. A particular path through the 
cis and DCC when coupled with a set of 
DCS operator consoles is commonly re- 
ferred to as a flight control string. The 
SOPC will eventually have a dual string 
capability which could provide simul- 
taneous support for two live missions, 
or one live and one simulation. In a 
non-mission environment, develop- 
ment work will also be performed on a 
string Or some portion of one. 
The SDPs are a set of large host com- 
puters. For Controlled Mode at JSC, the 


CREW/ 
INSTRUCTOR 
OPERATOR 
STATION IC 


INSTRUCTOR 
OPERATOR CREW 
STATION STATION 


Intelligence Controller 
Onboard Shuttle General 
Purpose Computer 


SDPs are four IBM System 370/168s. For 
SOPC they will be three or four (to be 
determined) current technology, 
upward-compatible replacements. The 
DCC is where the major real-time com- 
mand and control processing is per- 
formed in support of DoD Shuttle mis- 
sions. The applications which reside in 
the SDPs include telemetry, trajectory, 
command, network communications 
and an application executive. These ap- 
plications span the mission events from 
pre-launch to vehicle rollout. Figure 9 
shows the mission phases in a typical 
mission profile. In addition to the real- 
time programs, there are many offline 
or near-real-time programs used to sup- 
port the real-time and development 
environments. Included are such func- 
tions as hardware checkout, software 
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The DCC software (develope 
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ponent of the SOPc total (including Fpe 
FRE and FCE) of a projected 5.3 million 
lines. Figure 10 shows the Projected 
sizes of the major Sopc software com. 
ponents. 

The CSE provides the Capability to 
configure the SDP with communications 
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€quipment, shared peripherals and the 
DCS. It also supports selectover (switch- 
Ing to another computer) in the event 


of SDP failure or scheduled 
maintenance. 


Flight Control Element/ Display 
and Control System 


The Display and Control System pro- 
vides the capability for mission and 
Support personnel to request and moni- 


* Tracking 
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tor computer processed data in several 
media. The mission consoles at JSC are 
somewhat familiar to the viewing 
public as they are the ones usually 
televised during live mission coverage. 
These consoles have functional key- 
boards, television equipment, analog 
and event indicators and means for re- 
questing data from the CIS and DCC and 
for initiating commands and configura- 
tion instructions to FCE equipment and 
the Shuttle. In addition to the display 
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subsystem and the control subsystem 
whose functions have just been dis- 
cussed, the DCS also provides a timing 
subsystem which is the master timing 
service for all SOPC systems. 


Mission Development and 
Support 


At this point the major SOPC elements 
and their functions have been discuss- 
ed. A typical timeline and data flow 
through these elements and how they 
are used to prepare for and support 
DoD flights will now be described. 

The scenario for a DoD Shuttle mis- 
sion involves the launch site (Kennedy 
Space Center or Vandenberg), tracking 
network, the Shuttle vehicle, and SOPC 
(Figure 11). The mission sequence 
begins some three to four years prior to 
launch with the commencement of pay- 
load activities but the publication of the 
Payload Integration Plan (PIP) annexes 
at launch minus two years (L-2 yrs.) isa 
better indication of the start of the mis- 
sion process. 

There are two complexities of DoD 
flights to be considered. Low com- 
plexity is a repeat flight while high com- 
plexity is a first of its kind. The sched- 
ule of events is similar in content but 
the timelines are noticeably different. A 
timeline for software reconfiguration 
for the low complexity case is shown in 
Figure 12. The Mission Definition 
Change Request would occur at 
launch-234 days for the high complex- 
ity case as compared to launch-128 
days for the simpler one. The current 
assumption for the operational SOPC 
era is that 80 percent of the DoD flights 
will be of the repeat variety. 

Considering the low complexity case 
and referring to Figures 11 and 12 it is 
seen that the Mission Definition 
Change Request appears at L-128 days. 
This document specifies such items as 
payload, orbiter, trajectory and crew. 
This information and data generated 
from it begin to feed the components of 
the system. The Master Measurement 
Data Base (MMDB) is the major source 
for all SSV related measurement and 
stimuli information such as uplink and 
downlink formats, calibration con- 
stants, channelization data, command 
lists and data definitions. Products 
containing this information are gener- 
ated and sent to other systems for util- 
ization in mission related functions. 
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Configuration Requirements Pro- 
cessing (CRP) utilizes the MMDB data to 
generate reconfiguration products for 
other parts of the Flight Control 
Elements. The CRP products for a 
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FLIGHT CONTROL 


Se me typical flight may consist of over 7000 
DCS (0) products containing 600 megabytes of 


data and include air-to-ground teleme- 
try data, calibration constants, limit 
values, command data, vehicle perfor- 
mance data, SMCC configuration data 
and a wide variety of trajectory con- 
stants and model data. 

The DLPS produces mass memory 
load tapes for the onboard flight com- 
puters in the Fixed Base Crew Station 
Simulator and for the launch site to 
load the Shuttle onboard computers. 
The mass memory load tape has soft- 
ware elements for the primary and 
backup flight software systems, Space 
Shuttle main engine controller, display 
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units and other items like system 
loaders and telemetry format loads. 

Meanwhile the Crew Activity Plan 
(CAP) and the Flight Data File (FDF) are 
being generated. The former specifies 
detailed crew activity timelines and the 
latter specifies reference material for 
payload or Shuttle activities. The FDF 
includes such items as system check- 
lists, reference data and hardware such 
as clips, tethers and bags. At this point 
the SSV, the launch site and the Flight 
Readiness, Planning and Control Ele- 
ments are synchronized on the same 
data loads and can run integrated simu- 
lations, rehearsals and various types of 
pad tests. 

It should be clear that the above 
scenario is a single, simplified sketch of 
what is a complex process involving 
considerable feedback, multiple itera- 
tions and multiple versions (revision 
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Figure 11. A Shuttle scenario 


levels) of the data involved. Consider 
that for the DoD traffic model, there 
will be multiple missions at some stage 
of development at the same time and it 
becomes evident that configuration 
management and flight-to-flight recon- 
figuration tools are very important 
parts of the SOPC function. In essence 
flight-to-flight reconfiguration is the 
process of including flight specific data 
in a selected set of off-the-shelf soft- 
ware elements to create a software 
package for each data system for sup- 
port and operation of a given flight. 


Mission Types 


The utilization of the Shuttle provides 
DoD with the capability for a greater 
variety of mission types than possible 
with unmanned, non-returnable ve- 
hicles. In addition to the deployment 
mission, DoD can now perform 
retrieval, on-orbit servicing, on-orbit 
checkout, space construction and sortie 
missions. 

A sortie mission is one in which the 


payload remains attached to the Shuttle 
Orbiter and returns with it after a stay 
of up to thirty days in space. The sortie 
mission represents more involvement 
with the payload than normally envi- 
sioned for SOPC. This is because SOPC is 
a Shuttle oriented and not a satellite 
(payload) oriented facility. Once the 
payload is deployed, control of it is 
assumed by SOC where the payload 
data is processed by a Payload Mission 
Control Center (PMCC) within Soc. It 
was noted earlier that current plans are 
for SOC and SOPC to be co-located at 
CSOC. 

In addition to the mission types just 
discussed, a current DoD capability call- 
ed flexible launch is required for Shut- 
tle missions. Flexible launch refers to 
the capability to launch a spacecraft 
within a specified number of calendar 
days after notification. The concept in- 
volves peforming the flight preparation 
and readiness activities and then put- 
ting the system on hold. Periodic up- 
dates may be made until launch call is 
received at which time activities are 
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resumed, leading to a launch within the 
specified time frame, less than the 128 
days required for low complexity mis- 
sions. The objective of flexible launch 
is to provide DoD the capability to 
quickly replace a disabled or malfunc- 
tioning satellite. 


Transition/Interoperability 


It has been previously mentioned that 
prior to an operational SOPC, DoD Shut- 
tle operations will be conducted at JSC 
in the Controlled Mode environment. 
Close coordination will be required to 
transition from JSC to SOPC. The key 
elements of transitioning are direct DoD 
participation in Controlled Mode, utili- 
zation of NASA support and configura- 
tion control procedures and a phased, 
incremental, parallel approach to SOPC 
prime mission operations capability. 
The Air Force Manned Space Flight 
Support Group (MSFSG) stationed at JSC 
will support development and opera- 
tions for DoD flights in Controlled 
Mode. MSFSG will also train flight oper- 
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Figure 12. Shuttle mission timeline (operations era) 


ations support personnel who will tran- 
sition to SOPC to form the initial cadre. 

SOPC operational readiness will begin 
by running off-line with NASA provided 
flight tapes. Later, SOPC will function 
as live backup to a prime JSC for a DoD 
flight. Then, JSC will serve as a live 
backup to a prime SOPC for a DoD 
flight. SOPC will then assume a prime 
operational role with JSC in a cold 
standby or ‘‘call-up’’ mode. The plan 
calls for SOPC to use a Global Position- 
ing Satellite (see article on page 26) 
repeat flight to assume prime opera- 
tional support. 

The SOPC/JSC interoperability re- 
quirement could place stringent config- 
uration control procedures on both 
SOPC and JSC even after the transition 
phase. In essence, interoperability is the 
requirement for one center to perform 
specified functions of another center. 
For example, if SOPC were unable to 
continue mission support due to natu- 
ral or man-made causes, it is required 
that JSC be able to provide the 
necessary support to continue and con- 


clude the mission. 

This requires some degree of similar- 
ity in hardware, software, procedures 
and configuration products. The simi- 
larity could range from functional 
capability to identical replication and 
the exact degree has yet to be deter- 
mined. Suffice it to say that initiating 
DoD Shuttle capability at JSC, develop- 
ing SOPC and then transitioning to an 
operational SOPC while maintaining in- 
teroperability with JSC presents a 
noteworthy challenge. 


Summary 


The major activities for SOPC in the 
Shuttle operational era will be to recon- 
figure the software data systems, to 
train flight crews and flight operations 
support personnel and to control and 
monitor DoD Shuttle missions. The 
software reconfiguration is driven by 
changes in the vehicle, payloads, or 
mission profile. The concept for recon- 
figuring the software is that it will be 
mature and development will be at a 
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very low level. Therefore, reconfigura- 
tion is viewed as a data manipulation 
and verification process. To support 
the fast turnaround required by the DoD 
traffic model and to minimize the SOPC 
staffing level, there will be standardiza- 
tion of mission phases, reuse of data 
sets and more software tools to provide 
a high degree of automation. Flight 
crews will be provided by NASA and will 
receive flight specific training at SOPC. 
Flight Operations Support personnel 
will be trained using SOPC training 
systems. 

DoD and NASA are addressing flexible 
launch, interoperability, dual flight 
support, standard mission phases, JSC- 
to-SOPC transition and staffing level as 
well as the operational SOPC activities 
of flight-to-flight reconfiguration and 
flight personnel training. The tools and 
procedures being developed are aimed 
at providing DoD a low cost, reliable 
means for launching satellites and con- 
ducting space operations. 








The Launch Processing System 
for STS and DoD Space Shuttle 


by Don G. Satterfield 


Introduction 


Late r= gentlemen oe 
a Major test in the 
checkout and launch of the first re- 
usable Space Transportation System 
in April 1981. Its Outstanding perfor- 
mance demonstrated that the Lps can 
support the fully Operational Space 
ae Sropratty Including the planned 
es from Vandenberg Air 

Force Base, California. 

The LPS was developed by the IBM 
Federal Systems Division at its Cape 
Canaveral facility in conjunction with 
NASA at the Kennedy Space Center. 
The LPS concept reduces cost, mini- 
mizes launch turnaround time and in- 
creases the efficiency and effectiveness 
of the Shuttle launch team, thus en- 
abling the size of the team to be signifi- 
cantly reduced from the more than 
200-person team needed to launch an 
Apollo/Saturn vehicle. The need to 
automate checkout was evident very 
early in the Shuttle program if suffi- 
cient reductions in time from landing to 
re-launch were to be realized. 

This article reviews the history that 
indicated the need for a better system to 
launch reusable space vehicles (Figures 
1 and 2). Also discussed are: the LPS ar- 
chitecture using commercially available 
minicomputers, the challenges the 
design team faced in achieving a high 
level of system availability while con- 
trolling potentially hazardous functions 
(to both crew and vehicle) in a closed 
loop configuration (Figure 3), and the 
fault detection scheme and redundancy 
built into the system. The latter is to 
assure no impact to testing due to a 
hardware failure. Examples of these 
features are presented to indicate the 
protection provided for safe and 
reliable operations. Fault tolerance 
techniques were implemented in the LPS 
in those instances where redundancy 
was not a practical consideration. The 


article concludes with a summary of 
STS-1 performance data and a discus- 
sion of the future for LPS. 


Problem 


The challenge for the LPS designers was 
to develop a distributed minicomputer 
system that meets the stringent 


availability requirements for support- 
ing checkout and launch of the reusable 
Space Shuttle. The critical functions to 
be controlled in the real-time system 
dictated rapid fault detection, resolu- 
tion and reconfiguration. 


Figure 1. Firing room at Kennedy Space Center as it appeared for launch 
Of Apollo 11 and the first lunar mission. 
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History 


The manned space launches of the late 
1950s and early 1960s were accomplish- 
ed with the use of very little automa- 
tion. Issuing commands to the vehicle 
and responding to  out-of-tolerance 
measurements were accomplished 
almost entirely by people aided by 
semi-automated launch sequencers. 
Subsequently, the commitment to land 
a man on the moon and return him 
safely to earth in the decade of the Six- 
ties dictated the need for state-of-the- 
art vehicle checkout and launch team 
capabilities. This task was performed 








by two ground computers for the 
Saturn 1B and Saturn v launch vehicles. 
. These ground computers were tran- 
sistorized, large-scale, serial, digital 
computers. The one located in the 
Launch Control Center (LCC) com- 
municated, via a data link, with the 
other computer, located 3.5 miles away 
within the Apollo/Saturn Mobile 
Launcher (ML). Being serial computers, 
they were relatively slow (28 usec word 
time); however, they had the capability 
of issuing 2000 unique commands to 
the Launch Vehicle, while monitoring 
and performing limit checking of 
several thousand measurements. IBM’s 
Federal Systems Division designed and 
developed the ground computer soft- 
ware and, in addition, the Division 
operated and maintained the ground 
computer system. 

The two computers for checkout and 
launch of the vehicle were required to 
be operational and on-line (there was 
very little redundant or backup hard- 
ware); there were numerous single- 
point failures which could abort or 
cause a hold in vehicle checkout and 
launch. Another disadvantage of this 
system was that nearly 50 percent of the 
hardware was located within a few hun- 
dred feet of the launch vehicle. This oc- 
casionally meant that corrective main- 
tenance had to be performed by people 
in a very hazardous area. 

On most programs, where high avail- 
ability and stringent throughput re- 
quirements exist, the system objectives 
are achieved using custom hardware 
built to MIL-SPEC standards. However, 
while highly successful for Apollo/ 
Saturn goals, this approach could not 
meet the Space Shuttle objectives to 
reduce both development and opera- 
tional costs. One-of-a-kind hardware 
with special case maintenance and sus- 
taining engineering is expensive. 
Therefore, highly reliable parts were 
selected for use and lot shipments of 
parts were closely tracked through 
every phase of handling. 


New Concept Dictated 


A new concept for the automated 
checkout and launch of the Space Shut- 
tle was clearly dictated. In short, to 
meet the rapid turnaround time re- 
quirement of a reusable vehicle as well 
as to significantly reduce the number of 
people involved, the entire launch pro- 


cessing activity had to be automated 
with digital computers. But it had to be 
done in such a way as to preserve, from 
a functional point of view, the test 
engineer’s direct control over checkout 
and launch procedures. Therefore, a 
highly functional interface (Figure 4) 
between the user-engineer and the 
system was necessary, one that would 
not rely on a programmer to interface 
between a user and the system. This 
meant automation all the way from the 
test engineer up to the launch vehicle. 

In 1974, IBM was selected by NASA as 
co-architect to provide System Engi- 
neering and Software Development for 
the Launch Processing System. This 


- + — 


> ee 


selection, prior to hardware and com- 
puter procurement, allowed a total 
system design to be put in place for the 
LPS as contrasted to previous programs 
where the hardware was selected first 
and the software was then required to 
fit a “‘committed-to’’ system architec- 
tural design. 

This option was key to the success of 
the program. The NASA-IBM team con- 
ducted numerous trade-off studies to 
determine the allocation of processing 
functions. The results of these studies 
were tested and simulated to predict ef- 
fectiveness and performance for each 
key decision. 
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Figure 2. Firing room at Kennedy Space Center powered up fur the 
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integrated test of Space Shuttle Columbia, STS-1. 
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Distributed Minicomputer 
Network Architecture 
Selected 


A. distributed minicomputer network 
architecture was selected, one in which 
up to 64 minicomputers or micro- 
processors share a common 64K-word, 
high-speed pipeline memory to com- 
municate with each other. These com- 
puters perform basically five functions: 
(1) allow the operator to inter- 
face directly with the machine 
(2) interface with Ground Sup- 
port Equipment to issue commands 
and monitor and limit check 
measurements 
(3) interface with the Orbiter on- 
board computers of the 1BM avionic 
subsystem to issue system commands 


(__.) LOX STORAGE 
TANK 


COMMANDS. 
MEASUREMENTS 





COMMANDS- 


and monitor data 

(4) record most transactions in the 
64K shared memory 

(5) provide the capability to 
retrieve, format and print these pre- 
recorded transactions. 

Commercial minicomputers (MOD- 
COMP I1/45) were selected by NASA for 
the operational system. Each computer 
was upgraded to contain two asyn- 
chronous microprocessors, hereafter 
referred to as ‘‘option planes.’’ These 
option planes provide the capability to 
implement ‘“‘smart’’? 1/O channels and 
contain 1K words of 44-bit micro- 
programmable Read Only Memory 
(ROM) and, in some cases, 1K-words and 
16 bit scratch pad Random Access 
Memory (RAM). The CPUs are 16-bit 
parallel computers containing up to 64K 
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Figure 3. An example of a closed loop configuration. 


words of executable memory and up to 
256K of non-executable memory. Com- 
munication between a CPU and its two 
option planes is provided via the cpy 
instruction set, CPU memory, and Op- 
tion Plane-to-CPU interrupts. 

A key capability of the system is an 
inherent capacity for parallel testing of 
the launch vehicle. This means that 
from their consoles, test engineers 
engaged in the performance of separate 
procedures can invoke the necessary 
Support of other subsystems with 
minimum interference with other test 
procedures running against those sub- 
systems. The necessary access of these 
supporting subsystems must be avail- 
able to the test engineers without tying 
up any other test engineers. Also, the 
processing and monitoring of more 


Acronyms 


LOX - Liquid Oxygen 

FEP - Front End Processors 

GSE - Ground Support Equipment 

LDB - Launch Data Bus 

PCM - Pulse Coded Modulated Telemetry 
CDBFR - Common Data Buffer 

ET - External Tank 

Vi-2 - Electromechanical Valves 


Simplified Application Program- 
Start LOX Load 
Steps 
- Open ET vent (command) 
- Verify ET vent open (meas.) 
- Open V; (command) 
- Open V2 (command) 
- Verify Vi & V2 open (meas.) 
- If ET vent & Vi & V2 open 
then start LOX pump 
(command) 
7 - Monitor tank pressure 
and level measurements 


anf won — 


Close Loop Control 


lf ET pressure excessive 
Or ET vent fails closed 
Or V2 fails closed 

Or V: fails closed 

Then stop pump 





than 40,000 test parameters must be 
supported with real-time response cap- 
ability. And, the evaluation of test 
results must be near real time. 


LPS Architectural Overview 


A block diagram of the system that 
supported STS-1 is shown in Figure 5. 
There were 41 minicomputers involved 
in the checkout and launch of STS-1. 
Active and standby computer combina- 
tions are used to assure system avail- 
ability for key functions the LPS must 
support. However, this approach was 
not practical for the communication 
center of the network, the Common 
Data Buffer (CDBFR). The techniques 
implemented to assure data integrity 
for the CDBFR data transfers are 
discussed later in the article. 
The elements of the LPS fit into 
seven functional areas: 
¢ Common Data Buffer 
¢ Operator Control Stations 
e¢ Front-End Processors (FEPs) 
e Data Recording, Retrieval, and 
Monitoring 
e Hardware Interface Modules 
(HIM) 
e Transmission Line Conditioning 
and Switching 
¢ Host Computer 


Common Data Buffer 


The Common Data Buffer is a 64K, 
16-bit word and a 16-bit Error Correct- 
ing Code (ECC), 200 nanosecond N-MOS 
memory device that provides the com- 
munication center for the LPS. The 
common high-speed, shared memory is 
packaged in 32 cards of 64K by 1-bit 
memory planes. It provides for inter- 
rupt driven communications between 
computers and manages access conten- 
tion through a time-shared polling 
system of each connected processor. 
Any processor can ‘‘read’’ data from 
any location but ‘‘writes’’ to the 
CDBFR are restricted to predetermined 
private ‘‘write’’ areas. 

Thus, buffer overloading, which 
could cause an inordinate amount of 
buffer control overhead resulting in a 
data flow bottleneck, is avoided by 
allowing each computer to send only 
One message at a time to each of the 
other computers. The first message 
must be processed by the receiving 
computer before a second message can 
be sent. One computer can, however, 


send a message to 32 different com- 
puters at one time. Stack registers are 
provided to prevent overflow and 
message loss. 

Special microcode is resident in each 
minicomputer for interface with the 
common data buffer. Time reference 
for the LPS network and_ network 
switching is provided by using micro- 
processors interfaced to the buffer. 


Operator Control Stations 


Fifteen operator control subsystems are 
provided, each subsystem having three 
Operator stations. A minicomputer 
supports each subsystem. Data are 
displayed on a character graphic, color 
CRT display system. Commands are ex- 
ecuted and application procedure con- 
trol is exercised via the keyboard, pro- 
gram function key, or a programmable 
function panel. Up to six application 
programs can be executed concurrently 
in each console subsystem. A combina- 
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Figure 4. Test engineers at their LPS consoles 


. ° ro- 
tion printer/video copier is on ic 
vided to each console subsyste ae 
operator CRT position can be _ oe 
as part of the real time system Tie. 
remote terminal to the host sme anes 
These control stations are loade 7 
checkout procedures that eeneen * 
each station for a particular subsyste 
checkout. One console (Master) © ; 
responsible for managing the network, 
another (Integration) has the primary 
function of test integration. 


Front End Processors (FEP) 


The primary functions of the Front 
End Processors (FEP) are tO acquire 
data from the Shuttle Vehicle and 
Ground Support Equipment, detect 
out-of-tolerance measurements, maln- 
tain current status of each measure- 
ment in the Common Data Buffer, 
notify responsible control stations and 
issue commands to the systems that are 
being tested. There are four types of 





Front End Processors: 
e Pulse Coded Modulation (PCM) 


computers just as does any other on- 
board system, i.e., the FEPs are polled 


provided. The simultaneous logging of 


data to disk and tape provides the 
e Ground Support Equipment cyclically by the onboard computers. capability to play back, in near real- 

(GSE) The Uplink FEP provides the time, for analysis by test engineers. A 
° ae Data Bus (LDB) capability to issue commands to the Or- time tag logged with accuracy within 
e Uplin 


The PCM FEP receives telemetry 
streams from the Orbiter, decom- 
mutates it in accordance with pre- 
stored formats, and updates the Com- 
mon Data Buffer with the most current 
value of each measurement. 

The GSE FEP has a similar data ac- 
quisition function and, in addition, it 
controls a one-megabit ground data 
bus. Measurements are polled on a 
cyclic basis, via the data bus, ranging 
from one to one hundred times per sec- 
ond as defined by specifications con- 
tained in a Master Measurements data 
base. 

The LDB FEP provides the interface 
of the LPS to the Orbiter’s onboard 
avionics computer subsystem built by 
IBM. The FEPs respond to the onboard 
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DATA RECORD 









biter via the communication and track- 
ing network. This FEP formats com- 
mands from data obtained from inter- 
nal tables and from the information 
supplied by requesting consoles and 
transmits these commands via the com- 
munications network. A type of uplink 
FEP is provided to read selected data 
from the CDBER of interest to the NASA 
Marshall Space Flight Center at Hunts- 
ville, Alabama, and to transmit the 
data in real time to the Huntsville 
Operations Control Center. 


Data Recording, Retrieval 
and Monitoring 


The capability to record selected data 
that is being written to, or transferred 
across, the Common Data Buffer is 
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COMMON DATA BUFFER 


one millisecond of occurrence jis ap- 
pended to each transaction. 


Hardware Interface Modules 
(HIM) 


The HIMs provide the interface between 
the GSE FEP and the Ground Support 
Equipment such as the fuel pumps and 
other ground services to the Shuttle. 
The HIM converts digital data from the 
GSE FEPs to analog or discrete com- 
mands for the servicing equipment. 
The HIM is connected to GSE FEP via a 
One-megabit ground data bus. Mea- 
surements are also converted to serial 
digital data for transmission to the 
FEPs. Basically, HIM acquires measure- 
ment data and issues commands to GSE 
when requested by the FEP. 
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Figure 5. LPS support configuration. 
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Transmission Line 
Conditioning and Switching 


The Transmission line conditioning and 
switching matrix provides the capability 
to connect a Firing Room to a specific 
set of items being tested. This capability 
allows the same test equipment to be 
connected to the Shuttle vehicle at any 
location during the checkout process, 
i.e., Orbiter Processing Facility, Ve- 
hicle Assembly Building, or launch 
pad. The subsystem also provides 
signal levels compatible with the data 
bus onboard the Orbiter and an inter- 
face to the host computer for simulated 
inputs to the networks. 


The Host Computer 


The types of functions performed on 
the host machine, two Honeywell 
6680s, are data base management, 
high-level language compiling, and FEP 
table-builds. 

The IBM-developed support software 
that runs on the host provides the user 
with the capability to build the test con- 
figuration that will be loaded ‘into the 
minicomputer network. Elements of 
the support software include the high- 
level language compilers, data base 
management and FEP table-builds. The 
FEP tables describe measurements and 
commands, the Common Data Buffer 
(CDBFR) addresses, and PCM formats. 
The system-build process ties the user 
test program to CDBFR addresses, and 
formats the test configuration for 
loading into the minicomputer net- 
work. 

The host machines are also used to 
record real-time data via an interface 
with the common data buffer. One 
machine can be configured to provide 
models of vehicle subsystems for use in 
program debug and verification prior 
to Shuttle testing 


LPS Architecture Summary 


The LPS distributed minicomputer net- 
work has met the varied requirements 
of flexibility and high system availabil- 
ity. Redundancy management and re- 
configuration techniques are key to the 
system’s success. A number of techni- 
ques have been implemented through- 
out the system to assure command in- 
tegrity (Figure 6). The data transfer 
across the CDBFR will be discussed later 
in the article to provide a_ better 


understanding of some of the techni- 
ques implemented. 


Redundancy Management 
and Reconfiguration 


Management requirements of the re- 
dundant elements of the network cre- 
ated unique challenges to the LPS team. 
The backup computers had to be able 
to assume the active role in real-time 
with no loss of data. A switch of critical 


TO VEHICLE 
OR GSE 


HARDWARE 


-MANCHESTER II CODE 


-PARITY 


-GAP TIME CHECKS 


HARDWARE 


-ERROR CORRECTING CODE 


-MEMORY PARITY 


HARDWARE 


d to determine the 


operational status of network Os 
puters, each computer cyclically w an 
a health indicator to the Common Da 

Buffer. The health indicator consists 
of a status indicator and a chai 
System Integrity monitors this healt 

indicator and verifies the counter 
changes on successive cycles and deter- 
mines status changes. When a com 
puter’s health counter does not change 
on successive cycles, the program 


In the protocol use 


SOFTWARE 
-CHECKSUM 
-DATA BUS COMMUNICATIONS 
HANDSHAKE 
-VALID CONSOLE CHECK FOR 
COMMANDS 


-WORD COUNT CHECK 
-SUBSYSTEM INTEGRITY 


-ERROR CORRECTING CODE 


-BACK UP POWER 


-PRIVATE WRITE AREA VALID CHECKS 


HARDWARE 


-ERROR CORRECTING CODE 


-MEMORY PARITY 


Figure 6. Command and data integrity. 





function from one computer to another 
must be transparent to the test engi- 
neer. Data values in both active and 
standby units must be synchronized. 


Failed Element Detection 


A System Integrity program was 
developed to monitor the network com- 
puters and to control redundant com- 
puter switching. System Integrity con- 
sists of a monitor and control program 
which resides redundantly both in the 
Master and Integration Consoles and a 
slave program, called Subsystem In- 
tegrity, which resides at each network 
computer. 


Zi 


SOFTWARE 
-LOAD CHECKSUM 
-PREREQUISITE CHECKS 
-COMMANDS CHECKSUM 
-SYSTEM INTEGRITY 


notifies each network computer that 
the computer is not operational. Health 
counters are monitored at 40ms and 
500ms intervals. When an active com- 
puter of a redundant pair fails, System 
Integrity notifies each network com- 
puter that the system has switched to 
the standby computer. An active com- 
puter that detects a hardware problem, 
making it unable to perform its func- 
tion, requests an automatic switch to 
backup by setting switch request status 
in the health indicator. 

During the redundant switch pro- 
cess, Computer-to-computer communi- 
cations are redundantly managed to 
prevent loss of data. 


Orbiter Interface Control 
A Special Case 


The Launch Data Bus (LDB) FEPs con- 
trol the LPS interface portion of a 
bidirectional data bus communication 
link to the Shuttle Orbiter Data Pro- 
cessing System. LPS uses this link to 
command the Orbiter system to initiate 
stimuli to end-items such as _ aero- 
dynamic surface controls which are not 
under the direct control of LPs. Many 


CCMS SAFING* 


SOFTWARE 


HARDWARE SAFING 


CONSOLE 


SAFING PANEL 


CCMS SAFING* 
SOFTWARE 


of these stimulus functions are of a 
critical nature upon which the Safety of 
the Shuttle vehicle is dependent. In the 
prelaunch phase, the LPS is program- 
med to know when the stimuli func- 
tions are necessary. Onboard systems 
will not issue these stimuli automatic- 
ally. Furthermore, there are no direct 
connections from ground control sta- 
tions to Orbiter systems as was 
available in Apollo/Saturn systems. 
All communications are transmitted 


SWITCHING 


“LAUNCH PROCESSING 
SYSTEMS APPLICATION 
PROGRAMS SAFING 
SOFTWARE. INITIATED BY 
OPERATOR VIA HARD- 
WARE SAFING PANEL. 


BAC 


CONSOLE 


SAFING PANEL 





Figure 7. LPS application programs, safing software, flow diagram. 
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Over digital data buses. Consequently 

an LPS safety requirement is to main- 
tain bus communication with the Or- 
biter despite any LPs single-point hard- 
ware failure. Any recovery time involy- 
ed with a failure cannot exceed S00 ms. 
More importantly, no data loss is 
allowed on a single-point failure. In ad- 
dition, the LDB FEP must honor bus re- 
quests from multiple LPs consoles con- 
currently. 

To satisfy these requirements at the 
hardware level, there are two LDB FEPs, 
each with access to two launch buses 
(Figure 7). Any single FEP hardware 
failure or single bus failure will not per- 
turbate LPS/Orbiter communications. 
A “vehicle safing’’ interface also exists 
as a backup to the CDBFR in the event 
that it fails. The LDB FEP may receive 
“‘safing”’ interrupts that request it to 
issue safing commands to the launch 
bus. These commands are predefined 
by the user and loaded into the FEP at 
LPS initialization time. The LPS user 
issues a safing command by physi- 
cally throwing a ‘‘safing switch’’ 
located at an LPS console. This in turn 
causes the interrupt in the FEP as shown 
in Figure 7. 


Handling A Single FEP 
Failure 


The biggest problem encountered in 
satisfying the LDB redundancy require- 
ment was that of handling a single FEp 
failure. Specifically those failures of the 
component variety such as memory 
parity, power loss, CDBFR communica- 
tion channel failure, etc. The two LpB 
FEPs had to be ‘‘synchronized’’ in some 
sense so there is no data loss on single 
failure. However, the LDB FEP environ- 
ment is not conducive to such an effort. 
The two LDB FEPs do not receive bus 
Operation input requests from the LPs 
consoles simultaneously. Furthermore, 
the LDB FEPs do not have ultimate con- 
trol of the launch bus. The IBM on- 
board system initiates the protocol that 
controls the proper flow of data on the 
bus in both directions. It was found 
during LPS development that the FEPs 
could not stay truly synchronized in 
this environment where not only the 1/0 
events are asynchronous, but are non- 
Simultaneous between the two 
machines. 

The LDB FEP software was therefore 
augmented to include a ‘‘command 











management” package. Software amet 
cesses in the two FEPs are not identical; 
however, the internal state definitions 
of bus requests are maintained iden- 
tically in the two CPUs. The internal 
states are basically defined as: . 
a) requests pending bus uplink 
transmission 
b) requests transmitted and pend- 
ing Orbiter bus downlink response. 

The designated ‘‘active’’ FEP updates 
the ‘“‘standby’’ FEP with changes to the 
bus request internal states in order to 
maintain the CPU redundancy. Only the 
active FEP actually transmits data on 
the bus and answers onboard protocol. 
The standby FEP does not transmit, but 
it does receive Orbiter data. The stand- 
by FEP does not detect uplink bus 1/0 
events. 

Except for some _ special-purpose 
launch data bus operations that are not 
critical, the LDB FEP software guaran- 
tees no loss of the data bus on an FEP 
failure, even if it is the active FEP. This 
protection even extends to the extreme- 
ly unlikely cases where the active FEP 
fails between the completion of an 1/0 
event and the reporting of that event to 
the previous standby, now to become 
active, FEP. The ‘‘new’’ active FEP has 
the capability to detect this single 
anomaly in the internal state definition 
of bus requests, and to continue bus 
processing correctly. The engineer’s ap- 
plication programs are not perturbated 
on a ‘“‘FEP switchover,’’ except for an 
overall bus throughput time loss of ap- 
proximately 300 ms. 

Although the command manage- 
ment package only increased the LDB 
FEP-unique software size by 17 percent, 
the complexity of the software logic 
was Significantly increased. The redun- 


dancy overhead lies in the more com- 
plex ‘‘control’’ aspects of the software, 
rather than the simpler aspects, such as 
command buffer formation. 

Further protection is provided in the 
LDB FEP subsystem to allow for a “‘saf- 
ing only’? mode of operation (i.e., no 
CDBFR access) after a CPU power 
loss/restore. On the power restoration, 
the nucleus operating system software 
and the LDB FEP unique software purge 
all outstanding operating system data, 
re-establish all essential software queue 
structures, and re-enable the vehicle 
safing and launch bus transmit- 
ter/receiver interfaces. Orbiter safing 
commands may be subsequently up- 
linked to the launch data bus via the 
vehicle safing mechanism described 
previously. 

There has not been a single point 
failure in the LDB FEP subsystem in an 
operational environment during a ma- 
jor Shuttle test. However, repeated LDB 
FEP tests in which single failures were 
induced substantiate that the software 
does indeed maintain the proper launch 
bus communication with no data loss. 


A Fault Tolerant Example 


The common data buffer is the heart of 
the LPS, but could not be practically 
implemented in the conventional ac- 
tive/backup approach to high availabil- 
ity. Therefore, the system was im- 
plemented to be fault tolerant. Custom 
microcode was developed for the com- 
mon data buffer interfaces and it plays 
a key role in the fault tolerant system. 

The computer-to-computer commu- 
nication scenario (Figure 8) is described 
to explain the fault tolerant characteris- 
tics of the common data buffer. 
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Integrity of the Buffer is also Pt 
tected during commercial power a 
ures by providing it with pee ie 
able power. In the event of a facill y 
power loss, batteries that are maintain- 
ed on-line will provide power for 
enough time for diesel generators to 
start. Tests performed demonstrated 
no perturbations to system operations 
due to power switchover. 


Summary 


Support to one launch does not con- 
stitute total success for the LPS. 
However, data from the launch of 
sTs-1 indicated safe margins for plan- 
ned NASA and DoD launches (Figure 9). 
The challenge for the future is to pro- 
vide the user with better tools to fur- 
ther automate the checkout process, 
assist in customizing application pro- 
cedure for each launch, and streamline 
the system-build process to expedite the 
installation of mission-unique changes. 

Development is currently under way 
to add a secure communication capa- 
bility to the LPS to meet DoD re- 
quirements and to add enhancements 
to assure the system will meet the 
challenges of new payload checkout. 

Today, nine LPS systems are opera- 
tional with three additional planned for 
the future (Figure 10). 

Overall, the concept of a closed loop 
control system implemented by a 
systems network made up of commer- 
cially available minicomputers has 
been clearly demonstrated. Hardware, 
software and microcode techniques can 
be implemented to assure system data 
integrity and high system availability. 
(See pages 24 and 25 for Figures 8, 9 
and 10.) 
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Sending 

The sending cpu formulates a 
message with a corresponding 
check-sum. This message is writ- 
ten to the Buffer in its Private Write 
Area (PWA). All data written to the 
Buffer is transferred by the send- 
ing CPU's Buffer option plane. The 
option plane generates a 16-bit 
Error Correction Code (Ecc) word 
(for error detection and correction) 
for each 16-bit word transferred to 
the Buffer. The option plane sends 
the Buffer address, its correspond- 
ing Ecc word, datum to be writ- 
ten, and its Ecc word to the Buffer 
Access Card (BAC). Data ECC is 
transmitted over the address line 
and the address ECC is transmitted 
over data lines. This switch of Ecc 
precludes some hardware failure 
from perturbating data or address 
and accompanying ECc. The BAC 
places these four words on the bus 
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COMMUNICATION SCENARIO 


FEP acknowledges transaction b 
. Console receives j 
- (Not shown). Cons 


| / BUFFER SBBEh 
‘ey 
CONSOLE’S PWA 


TRANSACTION 


CONSOLE 


where the address and data are 
checked (and corrected if 
possible). The address is verified to 
be within the limits of the sending 
CPU's PWA and, if all is valid, the data 
and its Ecc are written into the Buf- 
fer memory. After the sending cpu 
has written the complete message 
in its PWA, it then writes the aa- 
dress of its Ppwa into the stack of 
the receiving CPU. 

The Buffer detects this input to 
the receiving cpu stack and 
generates an interrupt to the 
receiving CPU. The receiving cPuU 
reads the address from its stack to 
determine where to read the mes- 
sage. All data read from the Buffer 
is transferred through the receiving 
CPU’s CDBFR option plane. The op- 
tion plane sends the address and 
address Ecc to its BAC, requesting a 
read. The BAC places this address 


Figure 8. Computer-to-computer communication example. 
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. Console builds transaction in its Private Write Area (PWA). 

. Console places address of transaction in FEP's interrupt stack. 
FEP receives interrupt, reads its stack, obtains transaction address. 

FEP reads transaction from console’s PWA. 

y placing its identification in the console’s interrupt stack. 


nterrupt, reads its stack, and recognizes it as an acknowledge. 
ole reuses the PWA storage occupied by the transaction. 


on the bus where the address is 
checked and corrected if possible. 


Receiving 

If all is valid, the read is performed 
and the read data and its Ecc are 
sent to the receiving CPU’s BAC. The 
receiving CPU then can read the 
data and its Ecc and check the data 
for validity, correcting any correct- 
able errors. After reading the ad- 
dress of the message from its 
Stack, the receiving Cpu can then 
read the entire message from the 
Sending CPU's PWA. The receiving 
CPU does a check-sum of the 
message to compare to the check- 
sum generated by the sending cpu 
as a further data validity check. 
Any acknowledgement necessary 
is returned to the sending cpu in 
the same manner as the original 
message was sent. 
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LPS SETS 
Name Location Computers Status* 
Firing CKF 41 O 
Room 1 
Firing CKF 27 O 
Room 2 
Firing CKF 35 P 
Room 3 
Shuttle JSC 8 O 
Avionics Houston 
Integration 
Laboratory 
Serial #0 CKF 14 O 
Hypergolic CKF 5 O 
Maintenance 
Facility 
Complex CKF 12 O 
Control 
Cargo CKF 9 O 
Integration 
Test 
Equipment 
North VAFB, 24 O 
Vandenberg Calif. 
South VAFB, 34 P 
Vandenberg Calif. 
Solid Rocket CKF S) O 
Booster 
Orbiter ETR 2 P 
Function 
Simulator 


* O = Operational 
P = Planned 


T-5 T:4 
MIN MIN MIN 


2.179 APPLICATION PROGRAMS EXECUTED 
° 32,969 MEASUREMENTS MONITORED: 1 TO 100 TIMES PER SECOND 

7.970 COMMANDS TO VEHICLE AND GROUND SUPPORT EQUIPMENT 

TRAFFIC WITHIN LPS: MAX. 280 COMMUNICATIONS/SEC OR 42% OF MEASURED CAPABILITY 
* OUT OF TOLERANCE MEASUREMENT DETECTED: MAX. 5/SEC OR 2% OF MEASURED 


Figure 9. Performance items of interest for STS-1. 
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T-2.8 T-30 T-20 
MIN SEC SEC 


e MAXIMUM DATA LOGGING RATE: SUPPORTED 60K WORDS/SEC 


REACTION TIME TO DETECT OUT-OF-T 
CORRECT: 30 MSEC, SPECIFICATION 





Function Performed 


Support Launches 


Back up to FR-1 for ROT&E 
Launches 

Application Procedure 
Development Laboratory 


Support Launches 

Secure Communication 
Capability 

Ground/Onboard Avionics 
Integration 

Vehicle Application Procedure 
Debug and Verification 


System Software Development 
and Integration 


Shuttle Major Electromechanical 
Subsystem Refurbish and 
Revalidation 


Control of facilities such as 
water, electrical power, air 
conditioning, sound 
suppression 


Orbiter/Payload Interface 
Verification prior to inserting in 
Shuttle 


AF Application Procedure 
Develop 

Operationally support Orbiter 
Refurbish/Revalidation 

Control launches from Western 
Launch Site 

Solid Rocket Booster Avionics 
Checkout prior to stacking 

Orbiter Interface Verification of 
DoD Payload-Payload and 
Operation Control Center 
Interface 
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OLERANCE MEASUREMENT AND ISSUE COMMAND TO 
LIMITS TIME TO REACT: 250 MSEC 






Figure 10. Distribution and 
future plans for LPS locations. 
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The Operational Control System 
for the Global Positioning System 


by James J. Selfridge 


The Navstar, Global Positioning 
System (GPS), scheduled to become op- 
erational in the mid-1980s, is a space- 
based radio navigation system which 
provides position and velocity accurate 
to less than 16 meters and 0.1 meters, 
respectively, per second to users 
anywhere on the globe in any weather, 
day or night. 

The system is composed of three seg- 
ments. The Space Segment (Figure 1) 
consists of 18 Satellites, each one of 
which continuously radiates a signal 
containing the satellite’s precise posi- 
tion and an absolute time reference re- 
lated to a highly accurate onboard 
clock. The User Segment, planned for 
both military and civilian needs, air- 
craft pilots, ship Captains or field com- 


CONTROL 
SEGMENT 


bat soldiers, uses special-purpose, 
Passive (receive only) receivers, and 
computes exact, three-dimensional 
position and velocity from the signals 
of four or more of the satellites. The 
Control Segment monitors the position 
Of each satellite and the conditions of 
their onboard clocks and uses this in- 
formation to periodically update each 
satellite with current position predic- 
tions and absolute time corrections. 
The GPs is being developed by the 
Space Division of the U.S. Air Force 
Systems Command for the Department 
of Defense. DoD sees GPS initial costs 
for the military alone, over the next 20 
years, as being less than what it would 
cost to upgrade or replace today’s ex- 
isting radio navigation systems (LORAN, 


GROUND — 
ANTENNA 


Figure I. Global Positioning System operation. : 
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OMEGA, TACAN, and other similar 
systems). Performance of GPS was 
proven during the Concept Validation 
Phase conducted from 1977 through 
1979. In meeting all performance mea- 
sures, GPS demonstrated 10 times 
greater accuracy in navigation and four 
times more accuracy in weapons de- 
livery over other current or planned 
systems. Net cost benefits from the use 
of GPS is seen as approximating $57.6 
billion. 

The cost of providing an equivalent 
military capability without GPs is $59.7 
billion and the cost of maintaining cur- 
rent radio navigation systems is $3.3 
billion. The initial cost of GPS is $2.9 
billion and operations and maintenance 
costs through the year 2002 are $2.5. 





Thus, the net cost benefits from the use 
of GPS is seen as approximately $57.6 
Protea benefits to the civil 
community are typified by the GPS 
revolutionary impact on military mis- 
sions. Air traffic control, to cite one 
civil application, could be safer with 
higher density through the precise posi- 
tioning available with GPS. 

The IBM Federal Systems Division’s 
(Fsp) facility at Gaithersburg, Mary- 
land, has prime contractor responsibili- 
ty for the GPS Control Segment, also 
known as the Operational Control Sys- 
tem. To achieve system accuracy, the 
1pM-developed ground facilities will 
periodically measure each  satellite’s 
precise location, predict its position 
between contacts, calibrate the atomic 
clocks on board the satellites and pro- 
vide new navigation signals to the 
satellites. As part of the Operational 
Control System, IBM is providing a 
Master Control Station to be located in 
the central continental United States; 
five Monitor Stations to be distributed 
globally at surveyed sites to collect the 
satellite navigation signals; and three 
Ground Antennas also distributed 
globally to periodically update the sat- 
ellite’s navigation data and to com- 
mand the satellites based on satellite 
telemetry. 

IBM’s responsibilities include design, 
specification, development, installation 
and test of all IBM-supplied hardware 
and software, and the complete re- 
sponsibility to integrate the IBM- 
supplied components with government 
furnished equipment and facilities. In 
addition, IBM ground equipment must 
provide an RF interface to the satellites 
for uploading data and collecting sig- 
nals. All software used in the system, 
including that used to generate the 
satellite position and time estimates up- 
loaded to the satellites and radiated 
from the satellites to the user, has been 
specified by IBM as have the system 
manning requirements for operations 
and maintenance. 

The Operational Control System 
software, which integrates all require- 
ments, represents the single most signif- 
icant challenge to the successful devel- 
opment of the GPS system into a reli- 
able military support system, easily op- 
erated by available military personnel. 

The Operational Control System 
contract was initiated with IBM in Sep- 


tember, 1980. The full capabilities of 
the system will be implemented in the 
fall of 1985. During the U.S. Air Force 
Initial Operations and Test Phase, 
which lasts through early 1987, IBM will 
provide training and integration sup- 
port to the Air Force. Twelve subcon- 
tractors support IBM on the program, 
including the Harris Corporation for 
Ground Antennas, Stanford Telecom- 
munications, Incorporated for Monitor 
Station receivers and the OAO Corpora- 
tion for operations. 

The Space Division Joint Program 
Office for GPs development includes 
personnel of the U.S. Navy, U.S. Army, 
US. Marine Corps, the Defense Map- 
ping Agency, Department of Transpor- 
tation and nine NATO countries. GPS is 
now in full-scale engineering de- 
velopment and test, having completed 
the concept validation program in 
mid-1979. During the concept valida- 
tion, 775 test objectives were met. 
These included tests to demonstrate 
Navigation accuracy, threat perfor- 
mance (e.g. jamming), environmental 
effects (e.g. multipath, foliage atten- 
tuation, helicopter rotor modulation), 
and system characteristics of satellite 
clock and ephemeris accuracy, signal 
acquisition time, time transfer and sig- 
nal levels and structure. 

IBM is currently maintaining and op- 
erating the Phase I Control System at 
Vandenberg Air Force Base in Califor- 
nia. The Phase I Control System, de- 
veloped to support the GPS concept 
validation testing, consists of a limited 
satellite ephemeris and clock offset 
computation and upload transmitter 
facility at Vandenberg with four pre- 
liminary monitoring stations located at 
Vandenberg, Guam, Alaska and 
Hawaii. The U.S. Air Force Satellite 
Control Facility provides satellite te- 
lemetry and command capability prior 
to Operational Control System imple- 
mentation. An Initial Control System 
(ICS) will be installed at Vandenberg in 
by mid-1982, it will replace the Phase I 
System. The ICS will provide capability 
for an increased number of satellites 
over the Phase I Control System and 
will use one of the IBM 3033 computers 
to be installed in the Operational Con- 
trol System. This paper briefly de- 
scribes the navigation signal and the 
three GPS segments and discusses the 
significant design trades and features of 
the Optical Control System. 
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Navigation Signal 


The baseline constellation of 18 satellite 
vehicles (SVs) operates in near circular 
orbits of 10,898 nautical miles, at a 
55-degree inclination and with 12-hour 
periods. Since the GPS Satellite Vehicles 
are continuously radiating the naviga- 
tion RF signal, users can obtain preci- 
sion navigation data at any time, under 
all weather conditions and at any 
latitude, longitude or altitude. Depend- 
ing on their geographic location, users 
will be able to receive RF signals from 
between four and seven SVs of the 18 in 
the constellation. Each user determines 
its own position by measuring the 
transit time of the radiated navigation 

signal from any four SVs in view of the 

18 satellite constellation. User ac- 

curacies on the order of 16 meters in 

position and 0.1 meters per second in 

velocity are planned. 

Three SVs are needed to compute 
position, four SVs are needed to obtain 
time relative to the U.S. Naval Obser- 
vatory Universal Time Coordinated 
(UTC) to 0.1 microsecond. Signals are 
transmitted from the SVs on two L-Band 
frequencies (L1 at 1227.6 MHZ and L2 at 
1575.42 MHZ). The use of two frequen- 
cles permits corrections for ionospheric 
delay in signal transit time. Each 
L-Band frequency is modulated by 
pseudo random noise (PRN) codes and 
each L-Band frequency is further 
modulated by the navigation message. 
The PRN codes are the clear/acquisition 
(C/A) code at a 1.023 MHZ rate and the 
Precision (P) code at 10.23 MHZ. The 
C/A code is a 1023 bit Gold Code, with 
a unique code for each satellite. The 
code repeats each millisecond while the 
longer P Code repeats every 267 days. 
Each satellite is assigned a unique one 
week section of the long P code. Each P 
code section is reset to its initial value 
weekly. 

The 1500-bit navigation message 
frame (Table 1) is divided into five 
equal subframes and contains the 
satellite ephemeris data, the satellite 
clock offset data, and a subcom- 
mutated almanac of summarized posi- 
tion date for all satellites in the con- 
stellation. One word of each frame 
contains the almanac data for another 
satellite vehicle in the constellation. To 
obtain the complete almanac requires 
25 frames of data. The navigation 
message also contains other informa- 
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tion, such as the telemetry word (TLM) 
used by the control segment and user 
equipment for control and status. The 
navigation message is transmitted at 50 
bits per second, repeating every 30 
seconds. Each six seconds, at the begin- 
ing of each subframe, a Hand-Over 
Word (HOW) occurs. The HOW contains 
a count which allows a user to acquire 
the higher level, more accurate P code 
directly after the user has acquired the 
relatively short C/A code. 


The Space Segment 


The 18 satellites noted above with six 
Spare SVs comprise the Space Segment. 
Each Sv contains a Navigation Data 
Unit which includes control and storage 
for SV position data, atomic clocks, sig- 
nal generation and modulation equip- 
ment. SV position data and satellite 
clock correction data uploaded to the 


Table 1. Navigation Signal and Data 
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1.023 Mbps 

1.0 Second 
30. bps 
MHZ 


EACH SUBFRAME = 6 SECONDS 


satellite by the Operational Control Sys- 
tem are transmitted as the navigation 
message and modulates the L-Band sig- 
nals in addition to the P and C/A code 
modulation. Predictions of the satellite 
ephemeris and clock calibration func- 
tion are generated by the OCS for appli- 
cation hourly on the first day, then on 
successive four-hour periods for the 
next 13 days. The SV ephemeris is a set 
of parameters which precisely describe 
the SV orbital position referenced in 
time to earth coordinates. 

Each data upload is a full 14-day 
message of approximately 192,000 bits 
although each SV will receive newly 
computed inputs three times daily. The 
satellite Navigation Data Unit gates 
and transmits the stored message on 
time. In the event that data uploads do 
not occur, the satellite automatically 
provides data with gracefully degrading 
accuracy over 14 days. 
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Precise timing of the satellite trans- 
missions is controlled using the atomic 
clock signals. Each Sv has four atomic 
clocks, two Cesium and two Rubid- 
lum Frequency Standards and subsys- 
tems for electrical power; control of at- 
titude, velocity, reaction, temperature, 
telemetry and command; and RF equip- 
ment for receiving and transmitting. 
The Sv electrical system batteries are 
kept charged by solar panels. The at- 
titude and velocity control subsystems 
and the reaction control subsystem 
properly maintain the SV in the con- 
stellation. Louvers and heaters actuated 
by the thermal control subsystem cool 
and heat the subsystems. Operational 
Navigation Satellites, (ONS), which have 
a six-year mean mission duration and a 
10-year consumable supply, will be 
launched by the Space Transportation 
System Space Shuttle. Each Shuttle will 
launch from one to four satellites using 
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the Payload Assist Module D (PAM-D). 
The ONS Navigation subsystem is pro- 
tected against spoofing and cosmic ray 
upsets. Satellite survivability measures 
include command and upload encryp- 
tion and protection from laser, jam- 
ming and nuclear threats. 


User Segment 


The User Segment is extremely broad 
and provides for civilian as well as 
military applications. Users may be any 
suitably equipped aircraft, ship or sur- 
face vehicle as well as space vehicles 
and man-packs. Military applications 
include tactical and strategic recon- 
naissance, rendezvous, targeting and 
weapons delivery. Potential civilian ap- 
plications are air traffic control, ship 
navigation, oil exploration and 
goedesy. High dynamic aircraft may 
have multiple antennas to collect the RF 


Figure 2. Operational Control System overview. 
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signal from the SVs while maneuvering 
and may have multiple receiver chan- 
nels to compute positions to meet the 
real-time mission needs. GPS User 
Equipment is comprised of four prin- 
cipal components; including an anten- 
na, receiver, processor and input/out- 
put units. Receivers may be single 
channel which recover and process one 
signal at a time, sequentially processing 
multiple satellite signals; or receivers on 
a high performance aircraft may have 
up to five channels processing five P 
signal pairs simultaneously from up to 
five satellites. 

The receiver usually performs data 
detection and carrier tracking and fil- 
tering. The computer functions include 
receiver control, selection of satellites 
and signals to be used, correction of 
measurement data for propagation ef- 
fects, computation of position, velocity 
and time, and calibration of the 
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receiver. Inputs to the computer may 
include approximate satellite positions, 
time and vehicle altitude and attitude to 
aid in signal acquisition. Output from 
the GPS set may drive a display, or aid a 
vehicle control unit or weapons direc- 
tion unit. 


Control Segment 


Figure 2 provides an overview of the 
Operational Control System (OCS) and 
the major functions of its subsystems. 
The Monitor Stations (MSs) are unman- 
ned data collection subsystems which 
Operate under control of the Master 
Control Station (MCS). Tentative loca- 
tions for the Monitor Stations include 
Diego Garcia in the Indian Ocean, 
Ascension Island, Guam, Hawaii, 
Eastern Launch Site and the OCS MCS in 
Central U.s. Each Monitor Station can 
have up to 12 two-channel receivers 


which collect the L1 and L2 navigation 
signals from each satellite in view. 
(Note: The OCS is designed to accom- 
modate satellite growth to 24 active and 
eight spares from the 18 active and six 
spares in the current baseline. With 24 
satellites as many as 10 could be in view 
of a Monitor Station at one time), 

Tracking measurements from the 1] 

and L2 signals, including pseudo range, 
accumulated delta range and signal 
strength, are transmitted each 1.5 
seconds to the Master Control Station. 
Local meteorological measurements are 
also sent to the Master Control Station 
to compute a tropospheric correction. 
Two Frequency Standards, commer- 
clally available atomic Clocks, provide a 
local reference time and provide data to 
the Master Control Station on Monitor 
Station clock stability. The Navigation 
Data Message coming from the satellite 
at 50 bits per second is collected at the 
Monitor Station and forwarded un- 
modified to the Master Control Sta- 
tion. Data can be stored for up to five 
minutes at the Monitor Station to buf- 
fer communications outages. 

Three Ground Antennas (GAs) 
located around the world provide an 
S-Band communication link with the 
satellites for telemetry data collection, 
satellite commanding and navigation 
data uploading. GAs will normally 
operate under direct control from the 
Master Control Station receiving and 
transmitting signals, however, naviga- 
tion messages will be prestored one 
hour prior to upload and may be sent 
under local direction using the 
maintenance console at the GA site with 
voice coordination from the Master 
Control Station in an emergency back- 
up mode. 

The Master Control Station (MCS), 
which will be located at the Navstar 
Operations Center provides overall 
control of the GPS system. The NOC in- 
cludes the Master Control Station, the 
co-located Monitor Station, and Per- 
sonnel subsystem (PSS). A _ loosely 

coupled duplex IBM 3033N8 computer 
with specially designed interactive con- 
soles support mission operations per- 
sonnel. One or the other of the 3033N8s 
is designated as the primary or active 
processor. It performs time critical 
functions of the ephemeris and clock 
computation for the navigation mission 
and SV control and status under super- 
vision of the personnel in Mission Op- 
erations. Processing of critical func- 


tions can be provided by the backup or 
passive processor within 60 seconds if 
the active processor fails. The passive 
processor normally performs the less 
time critical functions of sv positioning 
for orbit maintenance, data base/soft- 
ware maintenance and training. 

Data Communications between sub- 
systems of the OCS is provided through 
dedicated voice grade communications 
circuits. Monitor-to-Master Control 
Station communications require 4800 
baud service; Ground Antenna to 
Master Control Station communica- 
tions require links of 9600 baud service 
to accommodate telemetry rates. Ter- 
minal support for voice, facsimile and 
telegraphic communications are also in- 
cluded in the design. 

The OCS was designed to facilitate 
24-hour-a-day operation with a small 
operations and maintenance crew with 
on-call specialists. The shift operations 
crew at the (MCS) (Figure 3) has three 
Pass Controllers to provide for three 
simultaneous OCS/SV contacts. 


The OCS Design Process 
and Subsystem Descriptions 


IBM was awarded the contract to 
develop the OCS as a result of a compet- 
itive design study which began in 
January 1979 and was completed with 
IBM’s selection for contract negotiation 
in July 1980. During the competitive 
design, numerous analytic tasks and 
trade studies in system engineering, 
hardware, software and system test and 
integration were performed. The fol- 
lowing sections describe some of these 
studies and analyses and provide addi- 
tional design detail. 


System Engineering and 
Architecture 


The OCS must meet a number of re- 
quirements in accuracy, SV protection, 
processing capacity, autonomy of oper- 
ation, SV prelaunch testing, various 
telemetry rates, built-in test and 
maintenance capability, and scheduling 
of the OcS itself. The driving perfor- 
mance requirements on the design are 
as follows: 

(a). support a total navigation error 
budget of <6 meters measured as 
user range error (URE). 

(b). provide at least one SV contact 
each eight hours to maintain Sv 
health. 
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(c). satisfy an OCS Mission Av 


allabilit 
(MA) of = 0.98 where oe 


Total No. of Contacts — 


MA = Missed Contacts 


Total No. of Contacts 


URE is defined as the error compo- 
nent along the line of sight between a 
user to the SV being evaluated, The 
navigation error budget is based on a 
SV clock with frequency stability of one 
part in 5 x 10"* over 28 hours. The ocs 
maintains the navigation error in 
bounds by continuously collecting 
satellite radiated navigation data at the 
Monitor Stations, generating new 
ephemeris and clock offset predictions 
for each SV as often as necessary each 
day at the Master Control Station and 
uploading the new ephemeris and clock 
correction data through the Ground 
Antennas. 

The algorithms, parameters and fre- 
quency of the computations should 
minimize the errors due to the instabil- 
ity of the SV clocks, unmodeled forces 
acting on each SV, and inaccuracies in 
the OcS data collection, measurement 
and computation process itself. Model- 
ed forces acting on the SVs include earth 
mass, solar gravity, lunar gravity, solar 
radiation pressure and gravity 
anomalies. 

Providing accuracy in position and 
time is the most important function of 
GPS. Therefore, the analysis and design 
trades associated with accuracy receiv- 
ed the highest priority during the design 
study. An experimental measurement 
station was built to collect measure- 
ment data to validate Monitor Station 
receiver design characteristics. In addi- 
tion, a stationary navigation process 
control system software module was 
programmed on an IBM System/370 
computer. Data were collected by the 
measurement station, processed 
through a model of the smoothing pro- 
gram, fitted to a Reference Trajectory 
obtained from the Naval Surface 
Weapons Center (NSWC) and used to 
predict an SV ephemeris. Then a 
navigation message suitable for upload 
was generated. When compared with 
the ‘“‘truth’’? model from NSWC the 
Root Mean Square (RMS) errors were 
7.3 meters. This result was surprisingly 
close considering the use of only one 
measurement station and of an esti- 
mated SV force model in the computa- 
tions. 

Extensive adaption of the TRACE 
Program developed by the Aerospace 


Corporation provided a capability to 
analyze clock error propagation, 
monitor station site locations, and to 
perform a sensitivity analysis highlight- 
ing design issues affecting accuracy. 
Table 2 summarizes the results of this 
analysis. While the sv clock instability 
has the most effect on system accuracy, 
the OCS is designed to overcome these 
effects with the Monitor Station 
receiver measurement, the navigation 
message upload strategy and GA site 
locations. Accuracy effects due to the 
number of Monitor station sites is low; 
however, the design provides five sta- 
tions globally to detect sv signal 
anomalies which could provide an in- 
dication of more serious SV problems. 
Monitor Station coverage of the 
available SV signal masked below :5 
degees for five potential Monitor Sta- 
tions is shown on Figure 4. Signals can 
be collected almost 95 percent of the 
time. Signal collection coverage is 
centered about each Monitor Station 
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location. In addition to accuracy con- 
siderations, GA site locations were af- 
fected by a need to assess the status of 
the electrical power system on the pro- 
totype SVs at least once every eight 
hours. 

Mission availability requirements of 
> 0.98 were met for the system by con- 
sidering the loss of components of each 
subsystem. Monitor Station equipment 
is not redundant since the system can 
Operate for short periods without all 
Monitor Stations or their channels. 
However, to improve Monitor Station 
availability and reduce station 
maintenance requirements, dual Fre- 
quency Standards are used, receiver 
channels will be programmable, and 
several receiver channels can be out 
before repairs are necessary. In the 
event of a GA/Master Control Station 
communication outage, the GA will 
have the capability to store telemetry 
until restoration and to prestore con- 
tingency input data for autonomous 
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upload up to one hour prior to trans- 
mission to avoid missed SV contacts. 
The Master Control Station design, 
with its duplex processors, will have 
cross strapped 1/O, GPS mission soft- 
ware allocated to processors on an on- 
line or deferrable basis and a one 
minute switchover between processors. 

Risk reduction across the system was 
achieved by the use of off-the-shelf 
computers, operating systems, real 
time executive and the selection of the 
Synchronous Data Link Control (SDL) 
protocol for data communication. The 
message block size for data com- 
munication between the Master Central 
Section and the Monitor Station and 
between the Master Control Station 
and GA was selected to meet the 
capabilities of the 10° BER circuits 
provided by the government. — 

Life cycle costs considerations re- 
sulted in the selection of commercial 
equipment and software whenever 
possible. The Master Control Station 
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will use the Command Control System, 
Control portion from the NASA Shuttle 
program as the real time executive. The 
Monitor Station and GA will use the 
same real time executive program. Un- 
manned operation of the Monitor Sta- 
tion and GA reduced overall manning 
needs. The capability designed into the 
MCS software and the display design 
allow the use of currently available 
skilled personnel in the Air Force. 


Operations Concept and 
Personnel Subsystem 


To formulate the Operations Concept 
and Personnel Subsystem all of the ac- 
tivities necessary to support the Naviga- 
tion Mission and the satellites were de- 
fined. Each requirement, e.g., satellite 
anomaly, ephemeris and clock predic- 
tion, data collection, etc., was analyzed 
and allocated to one of the OCS sub- 
systems. The allocated requirements 
were then expanded to determine the 
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frequency of occurrence, the criticality 
and the operator’s role in satisfying the 
requirements. 

SV support requirements, key to the 
GPS mission, received particular atten- 
tion. Navigation upload frequency, 
based upon accuracy requirements, 
normal orbit maintenance of the SVs 
and potential contingency situations 
were analyzed to establish the daily/ 
hourly SV support requirements. A SV 
Activity Summary, considered in the 
analysis, is shown in Figure S. 

Integrated timelines were developed 
which were the result of apportioning 
the OCS activities over a typical 24-hour 
period. Included were many normal 
and contingency mode scenarios. 

In developing the personnel sub- 
system, the timelines were analyzed 
along with OCS support activities to 
determine the number of personnel and 
the skills required to accomplish the 
mission. Existing Air Force skills were 
studied as were existing organizations 
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(Defense Support Program, Defense 
Meteorological Satellite Program) 
whose operations centers are similar to 
GPS. Minimizing the number of person- 
nel without sacrificing system effec- 
tiveness was a principal consideration 
to achieve low life cycle costs. 

The Personnel Subsystem consists 
of 85 airmen and 66 officers, was de- 
fined and requires current Air Force 
skills. The command structure, (Figure 
6) allocates responsibilities to the Mis- 
sion Operations crew and the support 
branches. 


Monitor Station Design 


The most significant Monitor Station 
design consideration was the collection 
Strategy for LI and L2 signal measure- 
ments from each SV to be selected for 
the Kalman Filter. The signal measure- 
ment process was considered the first 
half of a total selection process which 
includes the data editing, correcting 
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Figure 4. Monitor Station coverage provided by the GPS 


and smoothing prior to use of the 
Psuedo Range (PR) data in the estima- 
tion process. The measurement of 
range to the SV calculated from the 
signal transit time is called Psuedo 
Range since it contains bias errors due 
to SV clock and position uncertainties 
as well as other uncertainties. Analysis 
showed that the use of PR with Ac- 
cumulated Delta Range (ADR) (equiva- 
lent to integrated Doppler) to aid in 
smoothing the Pseudo Range results in 
a superior measurement product. This 
technique devised by IBM provides the 
optimum in error reduction, eliminates 
the introduction of bias terms and 
results in a significant reduction (600 to 
1) in computation time in the edit and 
smooth process. The technique requires 
a receiver to track ADR on both fre- 
quencies continuously and to track PR 
and ADR to within a constant bias. 
Such a receiver was built to IBM 
specifications for the experimental 
measurement station during the GPS 
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design study and demonstrated that the 
ADR measurements have the desired 
properties. 

The stations will be unmanned and 
operate automatically under control of 
the Master Control Station. Monitor 
Stations will be located in secure 
facilities at DoD bases. Maintenance will 
be provided through the host base on 
an on-call basis. As a result, the Master 
Control Station will be the capability to 
exercise and test the Monitor Station 
equipments (Figure 7) and isolate fail- 
ures, and the station itself is designed 
for simplified maintenance. For exam- 
ple, each receiver channel will always 
track an SV or a test signal generator so 
that failures can be immediately de- 
tected: channels will be assigned to the 
test signal generator to monitor abso- 
lute drifts prior to and just after track- 
ing; and idle time on receiver channels 
can be assigned as duplicate tracking 
channels to the same SV. The ground 
controller at the Master Control Sta- 
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tion is alerted to channel and station 
drifts as well as data which exceeds 
limit checks. 

The Monitor Station computer will 
be an IBM Series | with a remote Initial 
Program Load (IPL) capability from the 
Master Control Station. The computer 
will direct initialization, run diagnos- 
tics, Operate the interface with the 
Master Control Station using SDLC, im- 
plement the receiver tracking schedule, 
collect receiver channel data, collect 
local environment data of temperature 
and humidity, collect local status data, 
control the frequency standards and 
collect measurements of the phase dif- 
ferences between the two frequency 
standards. 

The receivers will use dedicated 
channels for tracking of an SV. Each 
channel has two demodulators for 
measuring ADR and PR at both L! and 
L2 frequencies. This provides 100 per- 
cent signal monitoring and maximum 
measurements. Only one P-code 
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Figure 6. Operational Control Center organization 
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lower risk than a distributed processor 
approach. 

A Master Control Station Computer 
sizing study was performed to estimate 
the size of the processor and its utiliza- 
tion given a functional design and 
operational workload. The sizing study 
led to the selection of the IBM 3033N8 
based on the Performance Results 
shown on Table 6. The estimated load 
was 42.38 percent for the 24 sv con- 
stellation, and four simultaneous 
streams of 8000 bits per second teleme- 
try. The processor was required to pro- 
vide 50 percent spare Capacity for ex- 
pansion. Representative software run 
to benchmark the processor provided a 
lower utilization, 32.62 percent, as 
shown. 

During the development of the Oper- 
ations Concept the interface between 
the operators and the OcS hardware/ 
software was analyzed. Particular at- 
tention was given to those human fac- 
tors aspects which would simplify the 
man-machine interface. Different types 
of displays, information content, com- 
mand actions, and alarm presentations 
were studied to determine the design of 
the mission operations consoles. 

In the resultant design each console 

consists of two color graphic CRTs, a 
light pen, alpha-numeric keyboard and 
program function keys. One of the 
CRTs is interactive, providing a means 
for schedule dispatching, SV command- 
ing, OCS reconfiguration, display selec- 
tion and system alarm indications and 
acknowledgment. The second CRT pro- 
vides for the display of detailed and 
summary status information. Primary 
operator input is through the use of the 
light pen and menus for dispatching the 
schedule, selecting displays, executing 
commands and acknowledging alarms. 
An operations language, based upon 
mnemonics with defined sets of argu- 
ments, provides for simple consistent 
input as well as system flexibility. Ten 
specially designed mission consoles are 
provided. Mission operations stations 
have an optional hard copy unit, which 
provides the operator with a record of 
events shown on the CRT. 

The station’s two-processor architec- 
ture requires that a reliable element also 
be able to detect a primary failure. The 
mission operations consoles each have 
access to both processors. Each console 
is able to detect within two to three 
seconds that the primary is not in con- 
trol. An alarm is issued at each console 


Table 5. MCS Load Requirements 
a 


Requirements 


Generate 4 navigation uploads per 
SV per day 


Generate 3 backup navigation up- 
loads per SV per day 


Process 4-8K bit telemetry streams 
simultaneously 


Receive SV tracking data contin- 
uously from 6 MSs at the rate of 4 
measurement sets per second 


Perform an estimate of SV orbit and 
clock state as Epoch every 15 
minutes for 24 SVs 


Service 4 command contacts per 
operational SV per day 


Receive and process station status 
data at one minute intervals from all 
stations 


Support one anomalous SV per day 


Perform trajectory generation com- 
putations on 32 SVs for preference 
ephemeris 


Two attitude determination sessions 
per day 


One attitude maneuver session per 
day 


Determination parameters for one 
thruster firing per day 


at which time the Ground Controller 
can initiate the recovery. This can be 
expanded to automatic switchover in 
the future. An important aspect of this 
approach is that the consoles remain 
operational and in control during the 
recovery process. 

To avoid frequent interrupt process- 
ing due to data needs of the GA and 
Monitor Station, a communications 
controller was designed into the con- 
figuration for responding to the ser- 
vicing needs of communication lines. It 
performs the line control, polling, ad- 
dressing, error recovery and buffering 
of data for efficient transfer to and 
from the main host processor. The con- 
troller selected is the IBM 3075 Com- 
munications Processor. 

As in the case of the main processor, 
two communication controllers are 
needed to provide the necessary redun- 
dancy. To provide flexibility in switch- 
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Notes 


Average is 4 per hour for 24 SVs 
Average is 2 per hour for 24 SVs 


This requirement represents a peak 
condition 


This data will be blocked to provide 
efficient use of the communication 
circuits and the communication 
interfaces 


Can be combined with navigation 
upload messages 


Telemetry included within the 4 
continuous streams 


Trajectory computations on opera- 
tional SVs (24) performed at 2 week 
intervals - non time critical 


No additional telemetry 


No additional telemetry 


No addition telemetry 





Over, each communication controller 
has separate and distinct connections to 
each processor. Each controller can 
handle the entire communication load. 

Direct access storage devices and 
tapes are also accessible by both pro- 
cessors so that programs, current data 
bases, and data logs are available in 
event of switchover. Those data sets 
whose loss would be catastrophic to op- 
erations are maintained in two copies 
through two independent data paths to 
two independent physical disks. Each 
program must leave the data base in a 
determinable position for recovery. 
When a disk or data path fails, opera- 
tion continues with the second copy un- 
til restoration is complete. The config- 
uration includes three IBM 3340s and 
three IBM 3350 Direct Access Storage 
Devices on each processor for a total of 
six. This provides 4.6 Gigabytes and 
slightly exceeds the requirement of 100 






Table 6. CPU Load 


ESTIMATED LOAD—3033N8 














Functional Utilization Functional Utilization 
Unit Percent Unit Percent 
Telemetry 12.33 GA Communications 1.29 
Ephem/Clock—prediction 7.42 System Performance Evaluation 1.21 
Misc. 5.61 Ground Status 0.20 
Ephem/Clock—estimation 4.79 MS Control 0.12 

MS Data Capture 3.01 Transmission Control 0.09 

MS Communications 2.51 Command Message Generation 0.05 

MS Data Processing 1.93 Upload Message Generation 0.02 
Control/Display 1.77 Tracking Message Generation 0.00 






TOTAL 42.38 percent 







BENCHMARK RESULTS—3033N8 
PROCESSOR UTILIZATION (%) 








Overall ccs CCS Ephemeris Navigation 
System MVS Services Telemetry Clock Sve. Upload 
1.5 Average 
Peak Load 35.18 13.65 3.54 4.73 5.08 8.18 
Average 
Peak Load 32.62 11.96 2.89 4.51 5.08 8.18 









.o Average 
Peak Load 28.98 9.56 1.84 4732 5.08 8.18 
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Figure 9. Master Control Station. 
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Table 7. Computer Program Functions 





SYSTEM/370 SOFTWARE 


Ephemeris and Clock 
e Data Editing 


Clock State Estimates and 
Estimate of Quality 

Ephemeris State Estimate and 
Estimate of Quality 

Ephemeris and Clock Predictions 
Generation of Upload Parameters 
System Time Monitoring 

MS Receiver Calibration 
Controller Alerting 

Ephemeris and Clock Prediction 
Performance Monitoring 


Network Control 


Network Configuration 

Control of GA Operations 

Control of MS Operations 
Including Receiver Scheduling 
OCS Subsystem Status Evaluation 
Readiness Tests of GAs and MSs 


Mission Scheduler 


Provides Immediate and Long 


Term Support Schedules Based 


on SV and OCS Needs 


System Log 
e 


Record Inputs, Outputs and Mis- 
sion Operation Events 
Condense, Merge, Compare and 
Create New Log Files 
Reconstructs Events and 
Sequences 


SV Command and Status 

e Telemetry Processing and 
Calibration 

SV Controller Alerting 
Command Generation 

GA Antenna Tracking Messages 
GA Pass Directory 

Navigation Upload Formatting 
Command Validation and 
Authentication 


Control and Display 

¢ Controls Console Configuration 

e Supports MCS Recovery 

e Provides Graphic and Alpha- 
numeric Displays 

e Processes Console Directives 

e Alarm Interpretation and 
Presentation 

¢ Controls Display Formats 


SV Positioning 

e SV Station Keeping and Attitude 
Control 

e Visibility Profiles 

e SV Momentum dump 
Computations 

e Eclipse Data 

e Solar Array Positioning Data 

e End-around Checks for Ephemeris 
and Clock 


Scenario Generator 
e Generates Telemetry and Naviga- 
tion Data for Testing and Training 


SERIES/1 SOFTWARE 


GA Program 


Station Configuration and 
Initialization 

Readiness and Diagnostic Testing 
GA/MCS Communication 

Antenna Pointing Angle Computa- 
tions and Antenna Control 
Telemetry Storage and Playback 


MS Program 


MS Configuration and 
Initialization 

Readiness and Diagnostic Testing 
MS/MCS Communication 

Control of Receiver Assignments 
Environmental Sensor Control 
Frequency Standard Control 


MS Receiver Microcode 

e Receiver Assignment Modes 
¢ Code Loop Control 

e Automatic Frequency Loop 
Control 

Phase Lock Loop Control 
Gain Control 

PR and ADR Measurements 
NAV Message Detection and 
Parity Checking 

e Receiving Diagnostics 
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percent reserve over the nee 
Gigabytes. IBM 3420 Tape 

high speed printers are su 
each processor. 


d for 2.26 
Units and 
Pplied for 


Computer Programs 


The functions of the Computer Pro- 
grams used in the Monitor and Master 
Control Stations and Ground Antenna 
are listed in Table 7. Estimates of the 
source lines of code in the mission pro- 
grams are approximately 350,000, In 
addition, IBM will provide more than 
250,000 off-the-shelf lines of code ex- 
clusive of the operating system. Soft- 
ware design and operations will use the 
full capabilities of OS/Vvs2 Multiple Vir- 
tual Storage. MVS provides job and task 
management, input/output access 
methods, memory management, and 
disk support. Its capabilities include 
maintenance aids and recovery man- 
agement facilities to support fault 
detection, isolation and repair of the 
MCS without mission support process- 
ing termination. 

To reduce system development risk 
the Command and Control System, 
Control portion (CCS/C) developed by 
IBM to support the NASA Shuttle pro- 
gram is used as the real time executive. 
The real time executive controls the 
processing of events which occur at 
random times, some dependent on ex- 
ternal events, some at scheduled events 
and others dependent on controller ac- 
tions. 

The Ground Antenna and Monitor 
Station both use the same real time ex- 
ecutive program which provides for the 
initial program load, supervisor ser- 
vices, data management, communica- 
tions with the Master Control Station, 
utilities, and debugging aids. 


Software Design Control 
Requirement 


The Navigation String (Figure 10) pro- 
vides one example of how the GPS con- 
trollers interface with the software 
through the mission consoles and the 
active processor. To support a naviga- 
tion upload, the Ground Controller 
oversees the OCS performance and will 
monitor the Monitor Station and GA 
status in collecting station measure- 
ments and telemetry prior to upload. 
Evaluating the performance of the 
Ephemeris and Clock Prediction pro- 
gram by reviewing intermediate calcu- 
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lations in the state estimation process is 

the Navigation Specialist. The Pass 

Controller will review the status of the 

SV prior to upload and oversee the 

operation of GA during the upload. 

The software provides the means for 
Pass Controllers to assess SV uploads 
through real time verification and to 
provide Navigation Specialists with 
straightforward approaches to modify- 
ing ephemeris and clock correction pre- 
diction parameters if navigation solu- 
tions deviate from known solutions. As 
mentioned above, the OCS software 
represents the single most significant 
challenge to the successful development 
of the GPS system into a reliable mili- 
tary support system, easily operated by 
military personnel. Consistent, reliable 
software is a must. The GPS software 
development process is taking advan- 
tage of those software engineering 
practices which have evolved in the 

Federal Systems Division. These jin- 

clude: 

1. Software design practices which 
provide a complete and coherent 
methodology for system definition, 
module design and program docu- 
mentation. 

2. Software development practices 
which provide languages, conven- 
tions and standards, and software 
development tools to manage the 
software as design specifications are 
reduced to code and the code is in- 
tegrated into a system product. 

3. Software management practices 
which provide the plans and con- 
trols for determining that the tech- 
nical schedule and cost performance 
goals for the product are being met 
from design through development. 
The software development process 

makes use of one of the IBM 3033N8s to 

be installed at the Master Control Sta- 
tion and an IBM Series 1 in a Software 

Development Laboratory (SDL) at IBM 

in Gaithersburg, Maryland. Telephone 


links will be provided to accommodate 
software development at the Initial 
Control System at Vandenberg and to 
subcontractor locations involved with 
developing software for ICS and OCs. 
Support software running under 
OS/MVS Time Sharing Option at the 
SDL includes the following software 
tools: 

structured programming facility 
program management facility 
program design language 

language processors 

library maintenance 

configuration management and re- 
porting 

e system build software 

© SCRIPT 


Summary 


The GPs System is planned to meet the 
DoD’s need for precise navigation into 
the 21st century. The OCS is designed to 
support the full space constellation of 
24 SVs and eight spare SVs as well as 
grow to meet expanding requirements. 
A secondary payload, the Integrated 
Operational Nuclear Detection System, 
will be on the GPS spacecraft. Ground 
control of that payload as well as other 
payloads which may be added later can 
be accommodated by the expansion 
capabilities of Operational Control 
System. 

Life cycle costs, particularly as they 
are effected by the number of people 
needed to operate and maintain the 
control system, were central to the 
design process and will continue to be 
of prime interest as the system develops 
and becomes operational. The software 
should provide further opportunity to 
reduce operator interaction and further 
minimize life cycle costs. 

In the years ahead, GPS will revolu- 
tionize military operations and pro- 
mises even greater benefits to civil 
needs. 


42 


Acknowledgements 


The OCS design effort reported on in 
this paper draws upon the contribu- 
tions of many people during the Stage | 
Study and Proposal and the subsequent 
efforts since the award of the OCS 
development contract. These included 
W.D. Carson for system engineering: 
S.G. Francisco for Overall technical 
leadership as well as Systems analysis in 
receiver design, ephemeris prediction 
Process and the clock predictor: R.D. 
Dancy system architecture and design; 
R.W. Gretz, Master Control Station 
architecture; R.C., Crutchfield, receiver 
design and ephemeris and clock soft- 
ware; J.E. Henrich, accuracy analysis; 
E.A. Keese, remote site location analy- 
sis and activity timeliness; D.R. Hope, 
Operations analysis and concept. The 
author expresses appreciation to S.G. 
Francisco, J.F. Durkin, D.M. Welsh, 
and A.B. Adkins who contributed 
many ideas and suggestions during the 
development of this paper. 


REFERENCES 


Material used in this paper was taken 
from the following sources: 


1. IBM, Federal Systems Division Pro- 
posal, NAVSTAR GLOBAL POSITION- 
ING SYSTEM, Operational Control Seg- 
ment with Analytic Tasks Study Reports 
dated April 25, 1980. 

z. Prin¢iple of Operation of 
NAVSTAR and System Characteristics, 
R.J. Milliken and C.J. Zoller. NAVIGA- 
TION, Journal of the Institute of Naviga- 
tion, Summer 1978. 

3. GPS Receiver Operation, B,J. 
Glazer NAVIGATION, Journal of the In- 
stitute of Navigation, Summer 1978. 

4. Signal Structure and Performance 
Characteristics, J.J. Spilker NAVIGA- 
TION, Journal of the Institute of Naviga- 
tion, Summer 1978. 

5. Reports and briefings prepared under 
U.S. Air Force Systems Command’s Space 
Division Contract F04701-80-C-0011. 


DSM: 
New Generation Of Satellite Control 


by Kenneth J. Deahl and Thomas C. Wellington 


The Air Force, through an industry The enh 
’ ancement ar; 
team headed by the IBM Federal , Known as Data 100,000 contact supports per ye 


ed System Modernization (DSM), also will together with other SCF upgrades, 
Systems Division, is advancing the improve operations and significantly ei will increase that to ae than 
Command and Control Segment of reduce operating costs by transferring 200,000 per year. (A contact support 
its worldwide Satellite Control Facil- more of the data processing work __ js the activity in a continuous interval 
ity (SCF) from second to fourth from the Remote Tracking Stations of communication between a satellite 
generation computer hardware and is to the Satellite Test Center located at and a Remote Tracking Station.) Fig- 
modernizing the system architecture. Sunnyvale, California. ure 1 shows the basic differences be- 
Under a six-year prime contract The present SCF network, built tween the current system and the 
which was awarded to IBM in around computer hardware based on modernized system. 

December 1980, IBM is upgrading the 


small-scale integration (SSI) com- Using commercially available IBM 
SCF network data system to handle —_ ponents from a variety of suppliers, is mainframes and small computers with 
the increased volume of space traffic barely keeping up with the workload. large-scale integration (LSI) com- 


expected into the next century. 


Current capacity is estimated at about —_ ponents, combined with off-the-shelf 
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technology, specialized interface 
hardware and software derived in 
part from current programs, DSM will 
transform the SCF’s operations from 
batch-oriented shared to centralized, 
interactive operations. Despite a pro- 
‘ected doubling of satellite contacts, 
DSM could reduce manning require- 
ments — an important saving. 

This capability to handle an in- 
creased load is based on a design simi- 
lar to that created by IBM for the 
Shuttle Ground Based System. It in- 
ludes the functions of realtime, in- 
teractive control of space vehicles and 
ground resoures from autonomous 
control centers; realtime processing 
of telemetry, tracking and_ status 
data; computer-interactive planning 
and evaluation functions (including, 
for DSM, full graphics displays for 
telemetry analysis); centralized con- 
trol of range resources; and an in- 
cremental approach to range schedul- 
ing automation. 

Among the driving factors in the 
DSM design (Figure 2), reliability is 
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Figure 2, Driving Jactors for DSM system design 


the principal one and requires 0.999 
probability of completing a 30-min- 
ute spacecraft contact. Also, al- 
though the 1984 system implementa- 
tion requirement is for about 30 Mb/S 
of telemetry data, DSM must be design- 
ed so that it can be upgraded to 525 
Mb/S. Technical risk and transition 
problems are to be minimized. 

Part of the overall Satellite Control 
Facility improvement program is a 
shift in communications mode from 
narrowband-landline links to wide- 
band satellite communications (the 
“bent pipe’). Under DSM, the 12 
antennas at seven Remote Tracking 
Stations at Vandenberg AFB; Thule, 
Greenland; United Kingdom; Guam; 
Hawaii; New Hampshire; and in the 
Indian Ocean will feed their data 
directly to the Satellite Test Center, 
which houses all the computers for 
dedicated Mission Control Com- 


plexes, the Range Control Complex 
and the System Development and 
Test Laboratory. The global operations 
of the SCF, including a Remote Vehicle 


REQUIREMENT/OBJECTIVE ARCHITECTURAL 
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ARCHITECT FOR GROWTH 
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SIMPLICITY 
RESOURCE DEDICATION 


Checkout Facilit 
are shown in Bieived. a ia 
Each of the Mission Control Com- 
plexes Operates autonomously for a 
designated Air Force Vehicle Office 
The Range Control] Complex has 
the demanding task of Overseeing all 
SCF resources (a task now Performed 
manually, for the most Part) to match 
the antenna and satellite schedules—a 
task that is expected to become even 
more demanding as the number of 
satellites in orbit £rows and includes 
more complex vehicles such as the Air 
Force Space Shuttle. The System 
Development and Test Laboratory is a 
replica of a Mission Control Comlex 
for developing and testing new control 
procedures and software. 


Five Segments in SCF 


To understand the significance of 
the Data System Modernization pro- 
gram, it is necessary to understand 
how the entire SCF works. There are 
five segments in the SCF, and DSM is 
the program to upgrade one of them, 







































the Command and Control Segment. 
This segment contains the data proc- 
essing, display, control, distribution 
and interface hardware and software 
necessary for Mission Control Com- 
plex operations, range planning and 
scheduling, range resource configura- 
tion control and the overall manage- 
ment of the SCF. The other segments 
are: 


Telemetry, Tracking and Com- 
manding Segment located at the 
Remote Tracking Stations and the 
Remote Vehicle Checkout Facility. 
This segment is composed of an- 
tennas, receivers, transmitters and 
signal conditioning equipment. The 
Telemetry, Tracking and Com- 
manding Segment performs pre- 
launch satellite checkout, acqui- 
sition and tracking of satellites, 
reception of telemetry and ranging 
data, transmission of commands to 
the satellite, and transmission to 
the Satellite Test Center of received 
telemetry and ranging data via the 


SUNNYVALE 


VANDENBERG 


Communications Segment. Track- 
ing and status data are routed to 
the Satellite Test Center via the 
DSM Remote Tracking Station/ 
Remote Vehicle Checkout Facility 
Control and Status Equipment 
(RCSE) associated with each anten- 
na. The RCSEs are part of the Com- 
mand and Control Segment and are 
included in the modernization 
program. 


Communications Segment, which 
has as its major function com- 
munication among all other seg- 
ments of the SCF system, NASA and 
other external users. The Com- 
munications Segment also per- 
forms communication security and 
data recording functions for the 
SCF. This segment provides the con- 
trol and interface equipment 
associated with the communica- 
tions satellites, landlines and mic- 
rowave circuits for transmission of 
data, voice, teletypewriter and fac- 
simile information. The baseline 
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Figure 3. Air Force Satellite Control facility network 
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NEW HAMPSHIRE 


‘‘bent pipe’? communications net- 
work consists of Dscs II relay 
satellites. A 9600 b/s landline is the 
backup for the Communications 
Segment. 


Support Segment, which includes 
the SCF timing equipment at each 
Remote Tracking Station and the 
Satellite Test Center, and the Camp 
Parks Communications Annex 
equipment that supports on-orbit 
satellite performance tests. The 
Command and Control Segment 
depends on this timing support for 
the functions of command trans- 
mission, command verification, 
telemetry recording and proc- 
essing, tracking/ephemeris proc- 
essing, configuration and status 
monitoring, simulation, data re- 
cording/archiving, display, vehicle 
clock calibration and hardware 
maintenance/ fault isolation. 


Facilities Segment, which provides 
the physical, electrical and environ- 
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mental elements that are required 

at the Remote Tracking Stations, 

the Remote Vehicle Checkout 

Facility, the Camp Parks Com- 

munications Annex, and the Satel- 

lite Test Center. 

DSM enables the Command and 
Control segment to be integrated with 
all the other segments of the SCF into 
a smoothly functioning system with 
greater throughput and reliability. 
Figure 4 shows an extension of the 
SCF to include a Satellite Operations 
Center at Colorado Springs, Colo- 
rado, which could be provided under 
a contract option to serve as an alter- 
nate Satellite Test Center. 


The DSM Team 


IBM’s Federal Systems Division, 
which has total system performance 
responsibility for DSM, heads a team 
of subcontractors and other IBM divi- 
sions. The program is managed from 
the IBM facility at Gaithersburg, 
Maryland, using many IBMers drawn 
from previous IBM space-related ef- 
forts such as Apollo, Skylab, and 
Space Shuttle. An additional IBM of- 
fice has been established and staffed 
at Sunnyvale for on-site support. 

Three other IBM divisions are par- 
ticipating in the program. The Data 
Processing Division (DPD) is supply- 
ing all the computer mainframes— 
three 3033 large-scale systems capable 
of operating at five million instruc- 
tions per second (MIPS) and seventeen 
4341 medium-scale systems operating 
at around 1 MIPS. The General 
Systems Division is supplying and 
maintaining 70 IBM Series/1 com- 
puters to serve as front-end pro- 
cessors. The Field Engineering Divi- 
sion is supporting the program with 
installation and on-site maintenance 
of DPD-supplied commercial hard- 
ware and software. 

The principal hardware subcon- 
tractor on the DSM team is Harris 
Corporation, which is developing the 
remote site RCSE subsystem for the 
Remote Tracking Stations and the 
Data Distribution Subsystem at the 
Satellite Test Center. Harris is 
responsible for the special interface 
equipment that will handle the in- 
creased data rates required in the 
enhanced DSM mode. 

Also supplying hardware is Sanders 
Associates, a manufacturer of high- 


resolution (1000 lines) color and 
monochromatic video display ter- 
minals to be used in the DSM consoles. 
The company is providing 42 dual 
screen terminals (graphics with color 
and monochrome). 

There are six software and engi- 
neering analysis subcontractors on 
the DSM team; four of them are 
designated small business concerns by 
the Small Business Administration. 
These six companies are: 

Litton Mellonics Division, develop- 
ing the commanding programs and 
the interface software to enable DSM 
to interface during the transition 
stage with present equipment that is 
to be retired. 

Infotec Development, Incorpo- 
rated (small business), handling the 
operational concept planning, display 
format design, man-machine inter- 
face, personnel requirements and 
DSM position handbooks. 

RDP, Incorporated (small business), 
providing the support software for 
maintenance and logistics. 

Computer Technology Associates, 
Incorporated (small business), sup- 
porting the development of the track- 
ing and orbit determination specifica- 
tions and algorithms. 
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Corporation (small business), de- 
veloping tracking and orbit deter- 
mination software. 

SCITOR Corporation, (small busj- 
ness), performing systems engineering 
for the test and integration activities. 

Completing the 1BM subcontractor 
team is Lockheed Missiles and Space 
Company (LMSC), which has provided 
Operations, engineering services and 
modifications support to the Air 
Force at the Satellite Test Center for 
20 years. As a participant in DSM, 
Lockheed has major responsibilities 
for planning the facility, preparing 
the site, installing the system, training 
Operations personnel, supporting the 
integrated logistics support manage- 
ment system, developing operational 
consoles and assisting the test and 
evaluation efforts. 


Hardware Commonality 


DSM introduces 10 new computer 
systems into the SCF. These are com- 
mercially available, state-of-the-art 
systems, each consisting of dual 
mainframes with shared peripherals 
and seven small computers. To avoid 
designing 10 separate computer com- 
plexes for 10 separate user groups— 
thus requiring ten complete system 
development and integration jobs—a 
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Figure 4. DSM system design 
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‘‘system kernel’’ architecture ap- 
proach has been used. 

A system kernel is the basic con- 
figuration that is duplicated for each 
of the Mission Control Complexes, 
the Range Control Complex and the 
System Development and Test 
Laboratory. All use dual IBM 
4341 processors except for the System 
Development and Test Laboratory 
and one Mission Control Complex 
which requires the greater power of 
3033s. Also, all of the kernels use the 
same standard IBM OS/MVS operating 
system. 

The system kernel architecture is a 
symmetrical configuration (Figure 5) 
that concurrently supports both the 
high priority task of realtime 
spacecraft contact support and lower 
priority planning and evaluation. The 
planning and evaluation processor 
can be switched to the higher priority 
task within 85 seconds, thus achieving 
a 0.9994 contact support mission 
reliability. The kernel CPUs share dual 
IBM Series/1 computers, which serve 
as front-end processors, a 
shared disk system averaging 5.5 
gigabytes of storage per Mission Con- 
trol Complex, five additional IBM 
Series/1 computers linking the system 
to the SCF network, and other periph- 
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Figure 5 . System kernel architecture 
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erals as needed, such as printers, tape 
units and displays. All equipment in 
Figure 5 is supplied by IBM commer- 
cial divisions except for the Sanders 
displays and the Harris Command 
Contact Support Equipment Group 
(CSEG) units which are part of the 
Data Distribution Subsystem. 

Hardware development is mini- 
mized through reliance on standard 
commercial data processing equip- 
ment, which offers the additional 
benefit of having sufficient compati- 
ble growth capability for future 
upgrades. An estimated 95 percent of 
all DSM hardware is off-the-shelf— 
70 percent through IBM commercial 
divisions and the other 25 percent, 
such as the displays and much of the 
Harris equipment, from other com- 
mercial suppliers. 

The remaining 5 percent, princi- 
pally the RCSE units from Harris, 
represents minimal technical risk. No 
new technology is involved, and there 
is no need for special integrated cir- 
cuits or custom processors. 


Software for Growth 


The DSM architecture will use 27 
Computer Program Configuration 
Items (CPCIs) plus mission unique 
Auxiliary Master Tape (AMT) CPCIs 






@ COMMON ADPE/CPCI NUCLEUS FOR EACH OF 
10 MCC/RCC/SDTL COMPLEXES 





@ DUAL PROCESSORS WITH SHARED DISKS, 
DISPLAYS, TAPES, PRINTER SETS 






@ DISPLAYS, DISKS, TAPES AND PRINTERS 
ADDED AS REQUIRED FOR MISSION 
SPECIFIC NEEDS 


© UPGRADE VERTICALLY WITH FASTER 
HARDWARE; HORIZONTALLY WITH MODULAR 
HARDWARE AND SOFTWARE 





@ AVERAGE 5,500 MEGABYTES OF DISK 
STORAGE PER MCC AND RCC 


® EITHER PROCESSOR CAPABLE OF EXECUTING 
CONTACT SUPPORT FUNCTION 


@ RAPID SWITCHOVER VIA HOT BACKUP FOR 
0.9994 CONTACT SUPPORT MISSION RELIABILITY 
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for a total of 1.2 million source lines 
of code (SLOG) to be delivered. This is 
in addition to 33 IBM licensed pro- 
gram software products, which repre- 
sent another 5 million SLOC. The DSM 
operating system will be the standard 
IBM OS/MVS equivalent to about 2.3 
million SLOC, complemented by the 
1BM-developed Ground Based Shuttle 
Real Time Support System (RTSS) to 
optimize throughput and responsive- 
ness. Both are also being used in the 
IBM development of the Navstar 
Global Positioning System Opera- 
tional Control Segment. 

Of the 1.2 million SLOC required 
specifically for DSM, 250,000 SLOC 
are available directly from existing 
IBM Federal Systems Division pro- 
ducts, and another 104,000 can be 
lifted and modified from these pro- 
ducts. This leaves 845,000 SLOC, or 70 
percent of the DSM requirement, to be 
developed as new code. 

In the initial DSM design phase, IBM 
examined a number of high order 
languages, including Ada, Jovial (J73 
version), Fortran and Cobol. The 
company chose Jovial J-73 as the 
primary language on the basis of its 
technical characteristics, availability 
in time to support the DSM mission, 
life cycle cost advantages, successful 
use for more than 10 years at the 
Satellite Test Center and its com- 
patibility for future transition to 
Ada, which is still in development. 

Jovial will be used for about 88 
percent of the new code with the 
balance being Assembler (10 percent) 
and Extendable Computer Simulator 
(2 percent) languages. The software is 
being developed incrementally in 
three phases—an initial group of 
CPCIs to support an early program, a 
second group for all other vehicle 
operations and a third for the AMT 
conversion to product vehicle specific 
software for each Mission Control 
Complex. The software distribution 
by code type is shown in Figure 6. 


Reducing Technical Risk 


The IBM design for DSM takes max- 
imum advantage of products and 
technologies proven in similar com- 
plex, realtime systems. Key features 
of this design that contribute to 
reduced life cycle costs and schedule 
risk minimization include the use of 


IBM commercial products (hardware tion, areas of technical, schedule and 
and software), existing products from __ cost risk were identified and assessed 
the Shuttle Ground Based System, at the beginning and the end of the 
Jovial J73 and modern software engi- design phase. The number of high 
neering technologies for software risk items was reduced from 10 to 
development, and a basic system zero during this phase and medium 
kernel architecture that is identical risk items, from 63 to 56. 

for all Mission Control Complexes, To support the development phase, 
the Range Control Complex and the IBM has established a program team 
System Development and Test Lab- at the Gaithersburg facility. An IBM 


tion and transition from the present 
system to the DSM mode. 

Hardware development begins with 
the flow of Preproduction models of 
the Data Distribution Subsystem / 
RCSE at Harris to IBM’s DSM System 
Development Laboratory at Gaithers- 
burg, consisting of a 3033 and 434]. 
This will be followed by checkout of 
initial production hardware at the 


oratory. facility with on-site staff at Sunnyvale System Development Laboratory jn 

Confidence in system performance is in place to provide systems engi- 1983 and additional checks of the 
is based on an analysis of specific re- neering support and to coordinate first four Operational RCSEs in Sun- 
quired tasks in the context of an with Air Force working groups on in- nyvale before delivery to the Remote 


operational concept. As part of the _ terface control, operations, telemetry Tracking Stations. Subsequent opera- 
design phase (1979-80), IBM ‘‘flew’’? a — processing and integrated logistics tional RCSEs are to be shipped directly 


simulated satellite constellation that — support management. Also at Sun- to operational sites so that each 
corresponds to the specified 1984 nyvale,a prototype Remote Tracking Remote Tracking Station has at least 
satellite scenario. The system load Station (without antennas) will be us- one RCSE prior to system Initial 
was established by modeling the space ed for test and integration. Operational Capability (10c). 
vehicle orbital characteristics, track- The software development phase, 
ing station performance and telem- DSM Implementation conducted principally at Gaithers- 
etry rates. The simulation considered Implementation of DSM (Figure 7) burg with support from the ais 
Remote Tracking Station utilization js proceeding in three overlapping subcontractors, is egress : 
and the scheduling and telemetry phases: hardware development (prin- use of FSD Software Deve susie 
loads for the SCF and each Mission cipally the RCSE and Data Distribu- Standards for top-down, sper 
Control Complex. tion Subsystem), software develop- programming. Development . me 
In addition to performance estima- ment and system test, and site activa- | of the CPCIs will be conducted in the 
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System Development Laboratory, in- 
cluding those produced by Mellonics 
in Sunnyvale and transmitted to 
Gaithersburg. System test and in- 
tegration are conducted in increments 
corresponding to the deliveries of 
hardware and software. Hardware 
development tests will be performed 
at Harris. Software tests, including 
Final Qualification Tests, will be per- 
formed in the System Development 
Laboratory by IBMers who will ac- 
company the software package to the 
Satellite -Test Center to assure a 
smooth transition to operational stat- 
us for each Mission Control Complex. 

The third implementation phase, 
site activation and transition, is com- 
plicated by the requirements that it be 
accomplished with minimum interfer- 
ence with on-going operations and 
without introducing any substantive 
risk to the space vehicles. Transition 
is done first at the Remote Tracking 
Stations as the RCSEs are installed and 
put in operation. Since compatibility 
with the pre-DSM and DSM modes 
must be maintained through the en- 
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Figure 7. DSM schedule 
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tire system transition period, a special 
hardware device known as the 
‘“‘Break-Out Unit’? from Harris 1s 
essential. It is installed in-line be- 
tween existing equipment to be re- 
tained and the new DSM hardware, 
and provides interface matching and 
rapid switching between modes. 

Satellite Test Center activation will 
involve a substantial role by Lock- 
heed in facility planning and training. 
IBM will manage implementation and 
transition from its Sunnyvale office. 
Survey plans, construction and site 
preparation are due to be complete 
for the first Mission Control Com- 
plex and the designated transition 
Mission Control Complex, MCC-T, in 
late 1983. The System Development 
and Test Laboratory should be ready 
for operation earlier that year. 

MCC-T is the key to continuing SCF 
Operations without interruption while 
DSM is being implemented. After be- 
ing trained first in the System Devel- 
opment and Test Laboratory, Air 
Force and civilian Vehicle Office (VO) 
people for each Mission Control 
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Complex to be transitioned will eae 
operational exercises IN MCC-T an 
proceed to qualification test an 
rehearsals. When the vo agrees that 
proficiency is at least equal to that 
achieved in the pre-DSM Mission Con- 
trol Complex, the VO then certifies 
DSM operations on MCC-T. The trans!- 
tioning Mission Control Complex 1s 
dismantled and outfitted with the new 
DSM equipment. The software is 1n- 
stalled and reverified, and DSM opera- 
tions begin in the pre-DSM MCC loca- 
tion. The next VO then starts its tran- 
sition on MCC-T. In this way, any VO 
has the ability to restore its original 
operations during the transition 
phase if problems arise. 

The total transition period for each 
vo involves about 16 weeks of train- 
ing, eight weeks of parallel operations 
and 15 weeks of facility conversion 
(Figure 8). 


Management 


In order to satisfy the unusual 
demands created by this complex 
system development activity, the 
challenging implementation schedule 
and the geographic dispersion of 
development and installation sites, 
special attention has been given to the 
management tools and techniques. 

As a cost and energy efficient 
method of coordinating the develop- 
ment work, video teleconferencing is 
being installed connecting the Sun- 
nyvale and Gaithersburg offices, and 
is under consideration for other loca- 
tions. This enables both large and 
small conferences to be conducted at 
substantial savings in both time and 
travel costs. 

In schedule management, the use 
of E-Z-PERT*, which provides graphic 
Outputs from tabular data bases, is 
providing flexibility of format and 
better visibility to critical paths in 
overall project schedules. In addition, 
near-term, detailed schedules are 
planned and reviewed in weekly meet- 
ings using computer prepared 
schedule charts. 

DSM program management person- 
nel have direct access to a com- 
prehensive project data base through 
deskside display terminals, providing 
the capability to search through a 
subject index of correspondence and 





* Registered Trademark, Systonetics, Inc. 


project coordination notes. All spec- 
ifications are being generated through 
a word processing system (‘‘SCRIPT’’) 
based in the System Development 
Laboratory computers. Traceability 
between specification requirements 
and analysis of the requirements are 
assisted by the use of the Problem 
Statement Language and Problem 
Statement Analyzer (PSL/PSA). 
Financial control is maintained in 
full compliance with DoD directive 
7000.2, and uses IBM’s automated 
system to provide weekly status and 
forecasts to cost account managers. 
These modern aids and approaches 
are used to augment traditional pro- 
gram management techniques in the 
areas of subcontract management, 
logistics management, quality as- 
surance, and configuration manage- 
ment. All system specifications and 
changes are under the control of the 
Configuration Control Board which 





brings the system engineering and 
development managers together at 
least weekly to address current 
technical issues. 


Summary 


DSM will meet the Air Force’s need 
for handling a growing volume of 
satellite contacts using fewer SCF 
Operational personnel by employing 
state-of-the-art hardware and soft- 
ware. Life cycle costs are further 
reduced by using commercially 
available systems with greater 
reliability and therefore lower 
maintenance requirements. Mission 
controllers will receive their data 
faster and in a more legible format 
through the interactive capabilities of 
DSM. 

Furthermore, the DSM architecture 
is inherently capable of growth to 
meet even more demanding require- 
ments. Horizontal growth can be 


achieved by adding more data 
streams and more Mission Control 
Complexes as necessary; vertical 
growth is ensured through large 
specified design margins and through 
the potential addition of higher 
capacity equipment, which would be 
compatible with the present hardware 
and software. DSM will bring major 
improvements to this vital defense 
program. 
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gram, and participation in the Mx Command and Control and 
Landsat D Image Processing System proposals. More recently, he 
was responsible for organization and management of the DSM early 
proposal activity. Dr. Deahl received his PhD in Physics from 
Carnegie-Mellon University in 1960 where he earlier received BS and 
MS degrees in Physics. 


Thomas C. Wellington, an IBMer since 1966, has held various 
management and systems engineering/technical assignments in the 
IBM Federal Systems Division, including the manager of the hara- 
ware Systems Engineering group for the IGLOO WHITE project and 
also the System Design Manager of the TRIDENT Command and 
Control System Engineering and Integration program. Technical 
assignments have included various engineering development respon- 
sibilities related to Sonar Signal Processors, Sonar Displays, and the 
IBM Series/I (MIL) computer. He is currently on the technical staff 
of DSM Systems Engineering. Prior to joining IBM, Mr. Wellington 
was associated with HRB-Singer and the Ordnance Research 
Laboratory of Pennsylvania State University where he earned a BS 
degree in Physics and an MS degree in Mathematics. 
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In the Previous Issue 


MIL-STD-1750: The Air Force 
Approach to Computer 
Standardization 

Many benefits are expected to accrue from 
this architecture; IBM’s participation in the 
program is described. 


The AN/UYK-43: A New Navy 
Standard Large 

Shipboard Computer 

This is supporting the Navy’s plan to 
sharply upgrade the functional capability, 
reliability and maintainability of the next- 
generation large shipboard standard 
computers. 


The AN/UYK-44: Militarized, 
Reconfigurable Processors/ 
Computers for the Navy 
Introduction of the AN/UYK-44 to the 
fleet will enable the Navy to improve 
small computer performance and 
reliability and to meet an increasing need 
for imbedded computers. 


The Army’s MIL-STD-1862 and 
the Military Computer Family 
The Army’s approach to computer 
standardization: a powerful architecture, 
extensive competition, and goals that 
anticipate major technology advances. 


The Role of DoD’s Ada in 
Software Standardization 

IBM’s Federal Systems Division is 
pursuing software standardization 
through the use of DoD’s Ada language, 
and an Ada-based software design 
language. 


LSI Applications in Military 
Systems 

The powerful building block approach of 
IBM’s Advanced Development Program 
master image methodology is being used 
in its first application—the associative 
comparator. 
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